* A few "linked checkout" niggles
@ 2015-07-15 23:13 Junio C Hamano
2015-07-16 5:24 ` Duy Nguyen
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Junio C Hamano @ 2015-07-15 23:13 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Eric Sunshine, git
I've tried to set up a non-bare clone of git.git at ~/w/src and
attached one of its branches to a separate work tree at ~/w/rerere
~/w/src$ git worktree add ../rerere jc/rerere
Then I tried the "multiple checkout not allowed".
~/w/src$ git checkout jc/rerere
fatal: 'jc/rerere' is already checked out at '/home/gitster/w/rerere/.git'
You see the first "niggle" above. Do we need "/.git" at the end?
That is hopefully merely cosmetic and I am guessing that we can
unconditionally drop "/.git" from the end, but maybe there are
subtle reasons why it may not be a good idea (e.g. introduces some
ambiguities?)
There is another, a more serious one.
~/w/src$ git fetch ../git.git jc/rerere:jc/rerere
This succeeds, without checking if there is a work tree that has it
checked out. I think the safety in "git fetch" that can be disabled
by "--update-head-ok" option should be updated to reuse the same
protection used by the updated "git checkout".
Something to work on for 2.5.x maintenance track, aiming for 2.5.1.
Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
@ 2015-07-16 5:24 ` Duy Nguyen
2015-07-16 5:40 ` Eric Sunshine
2015-07-16 20:39 ` Junio C Hamano
2015-07-17 12:27 ` Michael J Gruber
2 siblings, 1 reply; 11+ messages in thread
From: Duy Nguyen @ 2015-07-16 5:24 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Git Mailing List, Junio C Hamano
On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I've tried to set up a non-bare clone of git.git at ~/w/src and
> attached one of its branches to a separate work tree at ~/w/rerere
>
> ~/w/src$ git worktree add ../rerere jc/rerere
>
> Then I tried the "multiple checkout not allowed".
>
> ~/w/src$ git checkout jc/rerere
> fatal: 'jc/rerere' is already checked out at '/home/gitster/w/rerere/.git'
>
> You see the first "niggle" above. Do we need "/.git" at the end?
> That is hopefully merely cosmetic and I am guessing that we can
> unconditionally drop "/.git" from the end, but maybe there are
> subtle reasons why it may not be a good idea (e.g. introduces some
> ambiguities?)
>
> There is another, a more serious one.
>
> ~/w/src$ git fetch ../git.git jc/rerere:jc/rerere
>
> This succeeds, without checking if there is a work tree that has it
> checked out. I think the safety in "git fetch" that can be disabled
> by "--update-head-ok" option should be updated to reuse the same
> protection used by the updated "git checkout".
>
> Something to work on for 2.5.x maintenance track, aiming for 2.5.1.
To keep things clear, Eric if you want these they are yours :-) I'll
focus on the submodule support after i'm done with all my bug fix
patches.
--
Duy
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-16 5:24 ` Duy Nguyen
@ 2015-07-16 5:40 ` Eric Sunshine
0 siblings, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-16 5:40 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Junio C Hamano
On Thu, Jul 16, 2015 at 1:24 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I've tried to set up a non-bare clone of git.git at ~/w/src and
>> attached one of its branches to a separate work tree at ~/w/rerere
>>
>> ~/w/src$ git worktree add ../rerere jc/rerere
>>
>> Then I tried the "multiple checkout not allowed".
>>
>> ~/w/src$ git checkout jc/rerere
>> fatal: 'jc/rerere' is already checked out at '/home/gitster/w/rerere/.git'
>>
>> You see the first "niggle" above. Do we need "/.git" at the end?
>> That is hopefully merely cosmetic and I am guessing that we can
>> unconditionally drop "/.git" from the end, but maybe there are
>> subtle reasons why it may not be a good idea (e.g. introduces some
>> ambiguities?)
I can't think of any ambiguities which might arise from stripping the
.git suffix. Even when playing with GIT_COMMON_DIR and GIT_WORK_TREE,
I don't notice any ambiguities.
Since I'm already touching this code and am wrapping up v2 of [1], I
can easily plop in a fix for this cosmetic issue.
>> There is another, a more serious one.
>>
>> ~/w/src$ git fetch ../git.git jc/rerere:jc/rerere
>>
>> This succeeds, without checking if there is a work tree that has it
>> checked out. I think the safety in "git fetch" that can be disabled
>> by "--update-head-ok" option should be updated to reuse the same
>> protection used by the updated "git checkout".
>>
>> Something to work on for 2.5.x maintenance track, aiming for 2.5.1.
>
> To keep things clear, Eric if you want these they are yours :-) I'll
> focus on the submodule support after i'm done with all my bug fix
> patches.
I want to focus on getting v2 of [1] out and finalized. After that, I
might be able to take a look at the git-fetch issue (but I won't
complain if you get to it first).
[1]: http://thread.gmane.org/gmane.comp.version-control.git/273856
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
2015-07-16 5:24 ` Duy Nguyen
@ 2015-07-16 20:39 ` Junio C Hamano
2015-07-16 23:13 ` Duy Nguyen
2015-07-17 12:27 ` Michael J Gruber
2 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2015-07-16 20:39 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Eric Sunshine, git
Also in a linked checkout of git.git itself, t5601.21 seems to fail
with:
fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
not ok 21 - clone respects global branch.autosetuprebase
#
# (
# test_config="$HOME/.gitconfig" &&
# git config -f "$test_config" branch.autosetuprebase remote &&
# rm -fr dst &&
# git clone src dst &&
# cd dst &&
# actual="z$(git config branch.master.rebase)" &&
# test ztrue = $actual
# )
#
This test is running in /home/gitster/w/rerere, whose .git points at
that directory the fatail: message complains about.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-16 20:39 ` Junio C Hamano
@ 2015-07-16 23:13 ` Duy Nguyen
2015-07-17 3:11 ` Eric Sunshine
0 siblings, 1 reply; 11+ messages in thread
From: Duy Nguyen @ 2015-07-16 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Sunshine, Git Mailing List
On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Also in a linked checkout of git.git itself, t5601.21 seems to fail
> with:
>
> fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
> not ok 21 - clone respects global branch.autosetuprebase
> #
> # (
> # test_config="$HOME/.gitconfig" &&
> # git config -f "$test_config" branch.autosetuprebase remote &&
> # rm -fr dst &&
> # git clone src dst &&
> # cd dst &&
> # actual="z$(git config branch.master.rebase)" &&
> # test ztrue = $actual
> # )
> #
>
> This test is running in /home/gitster/w/rerere, whose .git points at
> that directory the fatail: message complains about.
I can't reproduce with either master, next or pu. Seems strange that
git.git info is leaking into this test..
--
Duy
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-16 23:13 ` Duy Nguyen
@ 2015-07-17 3:11 ` Eric Sunshine
0 siblings, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-17 3:11 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Junio C Hamano, Git Mailing List
On Thu, Jul 16, 2015 at 7:13 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Also in a linked checkout of git.git itself, t5601.21 seems to fail
>> with:
>>
>> fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
>> not ok 21 - clone respects global branch.autosetuprebase
>> #
>> # (
>> # test_config="$HOME/.gitconfig" &&
>> # git config -f "$test_config" branch.autosetuprebase remote &&
>> # rm -fr dst &&
>> # git clone src dst &&
>> # cd dst &&
>> # actual="z$(git config branch.master.rebase)" &&
>> # test ztrue = $actual
>> # )
>> #
>>
>> This test is running in /home/gitster/w/rerere, whose .git points at
>> that directory the fatail: message complains about.
>
> I can't reproduce with either master, next or pu. Seems strange that
> git.git info is leaking into this test..
I also am unable to reproduce the failure...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
2015-07-16 5:24 ` Duy Nguyen
2015-07-16 20:39 ` Junio C Hamano
@ 2015-07-17 12:27 ` Michael J Gruber
2015-07-17 12:49 ` Duy Nguyen
2 siblings, 1 reply; 11+ messages in thread
From: Michael J Gruber @ 2015-07-17 12:27 UTC (permalink / raw)
To: Junio C Hamano, Nguyễn Thái Ngọc Duy; +Cc: Eric Sunshine, git
Two more observations:
$ git worktree add /tmp/gitwt
Enter /tmp/gitwt (identifier gitwt)
Switched to a new branch 'gitwt'
Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
at the original branch.
So either we cd to the new location or quelch these messages or add a
message that we're actually back.
The other:
linked worktrees are prefect for short term tests on detached heads.
Even the manual page advertises detach. But:
$ git worktree add --detach /tmp/gitwtt
Enter /tmp/gitwtt (identifier gitwtt)
fatal: '--detach' cannot be used with '-b/-B/--orphan'
Maybe it's the auto-naming logic stepping on detached toes ;)
Michael
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-17 12:27 ` Michael J Gruber
@ 2015-07-17 12:49 ` Duy Nguyen
2015-07-17 15:19 ` Junio C Hamano
2015-07-17 17:02 ` Eric Sunshine
0 siblings, 2 replies; 11+ messages in thread
From: Duy Nguyen @ 2015-07-17 12:49 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Eric Sunshine, Git Mailing List
On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Two more observations:
>
> $ git worktree add /tmp/gitwt
> Enter /tmp/gitwt (identifier gitwt)
> Switched to a new branch 'gitwt'
>
> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
> at the original branch.
>
> So either we cd to the new location or quelch these messages or add a
> message that we're actually back.
s/Enter/Preparing/ ?
> The other:
>
> linked worktrees are prefect for short term tests on detached heads.
> Even the manual page advertises detach. But:
>
> $ git worktree add --detach /tmp/gitwtt
> Enter /tmp/gitwtt (identifier gitwtt)
> fatal: '--detach' cannot be used with '-b/-B/--orphan'
>
> Maybe it's the auto-naming logic stepping on detached toes ;)
Problem with master (but not with pu) because "-b gitwtt" is
automatically added. I think this is 1eb07d8 (worktree: add:
auto-vivify new branch when <branch> is omitted - 2015-07-06)
forgetting about --detach. Actually it's still a problem with 'pu'
because the branch 'gitwtt' is created unnecessarily.
--
Duy
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-17 12:49 ` Duy Nguyen
@ 2015-07-17 15:19 ` Junio C Hamano
2015-07-17 17:07 ` Eric Sunshine
2015-07-17 17:02 ` Eric Sunshine
1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2015-07-17 15:19 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Michael J Gruber, Eric Sunshine, Git Mailing List
Duy Nguyen <pclouds@gmail.com> writes:
> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Two more observations:
>>
>> $ git worktree add /tmp/gitwt
>> Enter /tmp/gitwt (identifier gitwt)
>> Switched to a new branch 'gitwt'
>>
>> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
>> at the original branch.
>>
>> So either we cd to the new location or quelch these messages or add a
>> message that we're actually back.
>
> s/Enter/Preparing/ ?
Hmm, do we even need that message? I assumed it was a leftover
debugging stuff ;-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-17 15:19 ` Junio C Hamano
@ 2015-07-17 17:07 ` Eric Sunshine
0 siblings, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-17 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Duy Nguyen, Michael J Gruber, Git Mailing List
On Fri, Jul 17, 2015 at 11:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Two more observations:
>>>
>>> $ git worktree add /tmp/gitwt
>>> Enter /tmp/gitwt (identifier gitwt)
>>> Switched to a new branch 'gitwt'
>>>
>>> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
>>> at the original branch.
>>>
>>> So either we cd to the new location or quelch these messages or add a
>>> message that we're actually back.
>>
>> s/Enter/Preparing/ ?
>
> Hmm, do we even need that message? I assumed it was a leftover
> debugging stuff ;-)
It helps give context to messages which follow it, such as "Checking
out files:..." and "HEAD is now at...", letting the user know that
those messages apply to the new worktree rather than the current one.
In this case, s/Enter/Preparing/ makes sense.
("Switched to a new branch..." is gone in 'pu'.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A few "linked checkout" niggles
2015-07-17 12:49 ` Duy Nguyen
2015-07-17 15:19 ` Junio C Hamano
@ 2015-07-17 17:02 ` Eric Sunshine
1 sibling, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-17 17:02 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Michael J Gruber, Junio C Hamano, Git Mailing List
On Fri, Jul 17, 2015 at 8:49 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Two more observations:
>>
>> $ git worktree add /tmp/gitwt
>> Enter /tmp/gitwt (identifier gitwt)
>> Switched to a new branch 'gitwt'
>>
>> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
>> at the original branch.
>>
>> So either we cd to the new location or quelch these messages or add a
>> message that we're actually back.
>
> s/Enter/Preparing/ ?
Presumably you're using 'master'. The "Switched to a new branch"
message is an artifact of using git-checkout for the back-end
operation, however, what is queued in 'pu' no long uses git-checkout
at all, so that message is gone.
I agree with Duy that s/Enter/Prepare/ would be a good idea. I don't
think we want to drop the message altogether as Junio suggested since
other messages such as "Checking out files:..." and "HEAD is now
at...." follow it, thus "Prepare..." provides context indicating that
those additional messages apply to the new worktree rather than the
current one.
>> The other:
>>
>> linked worktrees are prefect for short term tests on detached heads.
>> Even the manual page advertises detach. But:
>>
>> $ git worktree add --detach /tmp/gitwtt
>> Enter /tmp/gitwtt (identifier gitwtt)
>> fatal: '--detach' cannot be used with '-b/-B/--orphan'
>>
>> Maybe it's the auto-naming logic stepping on detached toes ;)
>
> Problem with master (but not with pu) because "-b gitwtt" is
> automatically added. I think this is 1eb07d8 (worktree: add:
> auto-vivify new branch when <branch> is omitted - 2015-07-06)
> forgetting about --detach. Actually it's still a problem with 'pu'
> because the branch 'gitwtt' is created unnecessarily.
Yep. Again, that fatal error is an artifact from git-checkout being
used as the back-end on 'master'. What is queued on 'pu' doesn't fail,
however, as Duy notes, the auto-vivication incorrectly kicks in and
creates a new branch unnecessarily. That'll have to be fixed in v3.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-07-17 17:07 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
2015-07-16 5:24 ` Duy Nguyen
2015-07-16 5:40 ` Eric Sunshine
2015-07-16 20:39 ` Junio C Hamano
2015-07-16 23:13 ` Duy Nguyen
2015-07-17 3:11 ` Eric Sunshine
2015-07-17 12:27 ` Michael J Gruber
2015-07-17 12:49 ` Duy Nguyen
2015-07-17 15:19 ` Junio C Hamano
2015-07-17 17:07 ` Eric Sunshine
2015-07-17 17:02 ` Eric Sunshine
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).