# A few "linked checkout" niggles 11 messages from 2015-07-15 to 2015-07-17. Participants: Junio C Hamano, Duy Nguyen, Eric Sunshine, Michael J Gruber. Thread: https://gitlist.dev/t/39858 ## Junio C Hamano, 2015-07-15 23:13 Subject: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/xmqqoajdui8w.fsf%40gitster.dls.corp.google.com ``` 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. ``` ## Duy Nguyen, 2015-07-16 05:24 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/CACsJy8CLYz7HqScS5Bxo47kTbrNj%3DqsaZnkKQ9ob4UVbjGG62Q%40mail.gmail.com In-Reply-To: ``` On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano 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 ``` ## Eric Sunshine, 2015-07-16 05:40 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/CAPig%2BcQ9V0rmZZrhB%3DdCu01kiCGpyNVmx7PeXQqBQ%3Dzvk_DF3g%40mail.gmail.com In-Reply-To: ``` On Thu, Jul 16, 2015 at 1:24 AM, Duy Nguyen wrote: > On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano 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 ``` ## Junio C Hamano, 2015-07-16 20:39 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/xmqqd1zr4z28.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` 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. ``` ## Duy Nguyen, 2015-07-16 23:13 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/CACsJy8CC_fju1Vy-hN69rKdpZ%3DXDUdZ_H_pmUb0bJdt-LdiPew%40mail.gmail.com In-Reply-To: ``` On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano 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 ``` ## Eric Sunshine, 2015-07-17 03:11 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/CAPig%2BcSB67wMs0T4OE9YS%3D2067bTvHeidx32PDGtu4O4q%3DnT2Q%40mail.gmail.com In-Reply-To: ``` On Thu, Jul 16, 2015 at 7:13 PM, Duy Nguyen wrote: > On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano 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... ``` ## Michael J Gruber, 2015-07-17 12:27 Subject: Re: A few "linked checkout" niggles Message-ID: <55A8F4B1.9060304@drmicha.warpmail.net> URL: https://gitlist.dev/e/55A8F4B1.9060304%40drmicha.warpmail.net In-Reply-To: ``` 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 ``` ## Duy Nguyen, 2015-07-17 12:49 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/CACsJy8BZEhMJPdw4K_kihA1kTPBVsAt%3DzW-cemzO7V%2BxfDih8Q%40mail.gmail.com In-Reply-To: <55A8F4B1.9060304@drmicha.warpmail.net> ``` On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber 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 is omitted - 2015-07-06) forgetting about --detach. Actually it's still a problem with 'pu' because the branch 'gitwtt' is created unnecessarily. -- Duy ``` ## Junio C Hamano, 2015-07-17 15:19 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/xmqqzj2u3j7m.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Duy Nguyen writes: > On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber > 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 ;-) ``` ## Eric Sunshine, 2015-07-17 17:02 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/CAPig%2BcRSHwmmF9cCUbRrDCCW4kvg9PeOUxP5VQpSGfxzMxHWOQ%40mail.gmail.com In-Reply-To: ``` On Fri, Jul 17, 2015 at 8:49 AM, Duy Nguyen wrote: > On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber > 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 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. ``` ## Eric Sunshine, 2015-07-17 17:07 Subject: Re: A few "linked checkout" niggles Message-ID: URL: https://gitlist.dev/e/CAPig%2BcSLs4-uKicVMBSKnEro_FYD722Hs1_U6qzTriM8Ciok2Q%40mail.gmail.com In-Reply-To: ``` On Fri, Jul 17, 2015 at 11:19 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber >> 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'.) ```