{"thread":{"id":"40660","subject":"What's the \".git/gitdir\" file?","startedAt":"2015-10-27T22:04:46Z","lastAt":"2015-12-31T05:59:48Z","messageCount":18,"participants":["Kyle Meyer","Stefan Beller","Randall S. Becker","Junio C Hamano","Mike Rappazzo","Nguyễn Thái Ngọc Duy","Eric Sunshine","Jeff King","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"272351","messageId":"87a8r4ary9.fsf@kyleam.com","threadId":"40660","inReplyTo":null,"subject":"What's the \".git/gitdir\" file?","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2015-10-27T22:04:46Z","receivedAt":"2015-10-27T22:04:46Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"Hello,\n\nWhen a \".git\" file points to another repo, a \".git/gitdir\" file is\ncreated in that repo.\n\nFor example, running\n\n    $ mkdir repo-a repo-b\n    $ cd repo-a\n    $ git init\n    $ cd ../repo-b\n    $ echo \"gitdir: ../repo-a/.git\" > .git\n    $ git status\n\nresults in a file \"repo-a/.git/gitdir\" that contains\n\n    $ cat repo-a/.git/gitdir\n    .git\n\nI don't see this file mentioned in the gitrepository-layout manpage,\nand my searches haven't turned up any information on it.  What's the\npurpose of \".git/gitdir\"?  Are there cases where it will contain\nsomething other than \".git\"?\n\nThanks.\n\n--\nKyle\ngit version 2.6.1\n"},{"id":"272352","messageId":"CAGZ79ka0XvmvVpX5WrpeEBXBWKA41RTZm4p7q=QtUTFy18hkoA@mail.gmail.com","threadId":"40660","inReplyTo":"87a8r4ary9.fsf@kyleam.com","subject":"Re: What's the \".git/gitdir\" file?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-10-27T22:22:34Z","receivedAt":"2015-10-27T22:22:34Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Oct 27, 2015 at 3:04 PM, Kyle Meyer <kyle@kyleam.com> wrote:\n> Hello,\n>\n> When a \".git\" file points to another repo, a \".git/gitdir\" file is\n> created in that repo.\n>\n> For example, running\n>\n>     $ mkdir repo-a repo-b\n>     $ cd repo-a\n>     $ git init\n>     $ cd ../repo-b\n>     $ echo \"gitdir: ../repo-a/.git\" > .git\n>     $ git status\n>\n> results in a file \"repo-a/.git/gitdir\" that contains\n>\n>     $ cat repo-a/.git/gitdir\n>     .git\n>\n> I don't see this file mentioned in the gitrepository-layout manpage,\n> and my searches haven't turned up any information on it.  What's the\n> purpose of \".git/gitdir\"?  Are there cases where it will contain\n> something other than \".git\"?\n>\n> Thanks.\n\nIt's designed for submodules to work IIUC.\n\nBack in the day each git submodule had its own .git directory\nkeeping its local objects.\n\nNowadays the repository of submodule <name> is kept in the superprojects\n.git/modules/<name> directory.\n\nIf you are in the submodule however you need to know where the repository is,\nso we have a file pointing at ../<up until superprojects root\ndir>/.git/modules/<name> directory.\n\nIf not using submodules, I'd expect that file to not be there.\nIf you have a file .git/gitdir which points to plain .git, this is\ntechnically correct,\nindicating where to find the repository (containing objects etc).\n\n>\n> --\n> Kyle\n> git version 2.6.1\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"272355","messageId":"017901d11108$ceb2cd10$6c186730$@com","threadId":"40660","inReplyTo":"CAGZ79ka0XvmvVpX5WrpeEBXBWKA41RTZm4p7q=QtUTFy18hkoA@mail.gmail.com","subject":"RE: What's the \".git/gitdir\" file?","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-10-27T22:42:48Z","receivedAt":"2015-10-27T22:42:48Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"-----Original Message-----\nOn Tue, October-27-15 6:23 PM, Stefan Beller wrote:\n>On Tue, Oct 27, 2015 at 3:04 PM, Kyle Meyer <kyle@kyleam.com> wrote:\n>> When a \".git\" file points to another repo, a \".git/gitdir\" file is \n>> created in that repo.\n>>\n>> For example, running\n>>\n>>     $ mkdir repo-a repo-b\n>>     $ cd repo-a\n>>     $ git init\n>>     $ cd ../repo-b\n>>     $ echo \"gitdir: ../repo-a/.git\" > .git\n>>     $ git status\n>>\n>> results in a file \"repo-a/.git/gitdir\" that contains\n>>\n>>     $ cat repo-a/.git/gitdir\n>>     .git\n>>\n>> I don't see this file mentioned in the gitrepository-layout manpage, \n>> and my searches haven't turned up any information on it.  What's the \n>> purpose of \".git/gitdir\"?  Are there cases where it will contain \n>> something other than \".git\"?\n>\n>It's designed for submodules to work IIUC.\n>\n>Back in the day each git submodule had its own .git directory keeping its local >objects.\n\n>Nowadays the repository of submodule <name> is kept in the superprojects >.git/modules/<name> directory.\n\nSlightly OT: Is there any way of avoiding having that file in the first place? I'm hoping to have a git repository in a normal file system (Posix) and a working area in a rather less-than-normal one where dots in file names are bad (actually a dot is a separator).\n\nCheers,\nRandall\n"},{"id":"272356","messageId":"CAGZ79kaXdjxT2jbHGHYPN0Bnk_4ZFrPo0sXKUrVvynoMfLPjCQ@mail.gmail.com","threadId":"40660","inReplyTo":"017901d11108$ceb2cd10$6c186730$@com","subject":"Re: What's the \".git/gitdir\" file?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-10-27T22:54:02Z","receivedAt":"2015-10-27T22:54:02Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Oct 27, 2015 at 3:42 PM, Randall S. Becker\n<rsbecker@nexbridge.com> wrote:\n> Slightly OT: Is there any way of avoiding having that file in the first place? I'm hoping to have a git repository in a normal file system (Posix) and a working area in a rather less-than-normal one where dots in file names are bad (actually a dot is a separator).\n\nAs said before, I would not expect a file .git/gitdir to be there if\nnot using submodules.\nFor your OT question, I'd presume you'd have environment variables setup\n    export GIT_DIR=path_with_no_dots_and_git_repo_in_it # you mention\nthat is in your posix FS\n    export GIT_WORK_TREE=/some.place.with.dot.separators\nand you'd be good to go.\n\n\n>\n> Cheers,\n> Randall\n>\n"},{"id":"272357","messageId":"xmqqpozzncs0.fsf@gitster.mtv.corp.google.com","threadId":"40660","inReplyTo":"87a8r4ary9.fsf@kyleam.com","subject":"Re: What's the \".git/gitdir\" file?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-27T22:54:07Z","receivedAt":"2015-10-27T22:54:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kyle Meyer <kyle@kyleam.com> writes:\n\n> When a \".git\" file points to another repo, a \".git/gitdir\" file is\n> created in that repo.\n>\n> For example, running\n>\n>     $ mkdir repo-a repo-b\n>     $ cd repo-a\n>     $ git init\n>     $ cd ../repo-b\n>     $ echo \"gitdir: ../repo-a/.git\" > .git\n>     $ git status\n>\n> results in a file \"repo-a/.git/gitdir\" that contains\n>\n>     $ cat repo-a/.git/gitdir\n>     .git\n\nSounds like a bug in the recently added \"worktree\" stuff.  Perhaps\nupdate_linked_gitdir() tweaked by 82fde87f (setup: update the right\nfile in multiple checkouts, 2015-08-25) is misbehaving?\n"},{"id":"272358","messageId":"CANoM8SWDHyS1P=o1FwZUnE4OVUhhFS+-dFfgPQPE-zeHtGAp3A@mail.gmail.com","threadId":"40660","inReplyTo":"xmqqpozzncs0.fsf@gitster.mtv.corp.google.com","subject":"Re: What's the \".git/gitdir\" file?","fromName":"Mike Rappazzo","fromEmail":"rappazzo@gmail.com","sentAt":"2015-10-27T23:26:34Z","receivedAt":"2015-10-27T23:26:34Z","isPatch":false,"sender":{"key":"rappazzo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/525287?v=4"},"body":"On Tue, Oct 27, 2015 at 6:54 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Kyle Meyer <kyle@kyleam.com> writes:\n>\n>> When a \".git\" file points to another repo, a \".git/gitdir\" file is\n>> created in that repo.\n>>\n>> For example, running\n>>\n>>     $ mkdir repo-a repo-b\n>>     $ cd repo-a\n>>     $ git init\n>>     $ cd ../repo-b\n>>     $ echo \"gitdir: ../repo-a/.git\" > .git\n>>     $ git status\n>>\n>> results in a file \"repo-a/.git/gitdir\" that contains\n>>\n>>     $ cat repo-a/.git/gitdir\n>>     .git\n>\n> Sounds like a bug in the recently added \"worktree\" stuff.  Perhaps\n> update_linked_gitdir() tweaked by 82fde87f (setup: update the right\n> file in multiple checkouts, 2015-08-25) is misbehaving?\n\nI noticed that as I was working on the worktree list command that my\nlinked worktree gitdir files were being clobbered to '.git'.  I\nattributed it to my work, but now that you mention it, I think it has\nhappened with the 2.6.1 release as well.\n"},{"id":"272417","messageId":"xmqqwpu7klmu.fsf@gitster.mtv.corp.google.com","threadId":"40660","inReplyTo":"CANoM8SWDHyS1P=o1FwZUnE4OVUhhFS+-dFfgPQPE-zeHtGAp3A@mail.gmail.com","subject":"Re: What's the \".git/gitdir\" file?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-28T16:23:21Z","receivedAt":"2015-10-28T16:23:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Rappazzo <rappazzo@gmail.com> writes:\n\n> On Tue, Oct 27, 2015 at 6:54 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Kyle Meyer <kyle@kyleam.com> writes:\n>>\n>>> When a \".git\" file points to another repo, a \".git/gitdir\" file is\n>>> created in that repo.\n>>>\n>>> For example, running\n>>>\n>>>     $ mkdir repo-a repo-b\n>>>     $ cd repo-a\n>>>     $ git init\n>>>     $ cd ../repo-b\n>>>     $ echo \"gitdir: ../repo-a/.git\" > .git\n>>>     $ git status\n>>>\n>>> results in a file \"repo-a/.git/gitdir\" that contains\n>>>\n>>>     $ cat repo-a/.git/gitdir\n>>>     .git\n>>\n>> Sounds like a bug in the recently added \"worktree\" stuff.  Perhaps\n>> update_linked_gitdir() tweaked by 82fde87f (setup: update the right\n>> file in multiple checkouts, 2015-08-25) is misbehaving?\n>\n> I noticed that as I was working on the worktree list command that my\n> linked worktree gitdir files were being clobbered to '.git'.  I\n> attributed it to my work, but now that you mention it, I think it has\n> happened with the 2.6.1 release as well.\n\nThanks; I trust those who worked on the worktree feature in 2.6\ntimeframe would first take a look, OK?\n"},{"id":"272746","messageId":"1446491306-13493-1-git-send-email-pclouds@gmail.com","threadId":"40660","inReplyTo":"xmqqwpu7klmu.fsf@gitster.mtv.corp.google.com","subject":"[PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-11-02T19:08:26Z","receivedAt":"2015-11-02T19:08:26Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"$X/gitdir is created, or refreshed, in order to keep a linked worktree\nfrom being pruned. But while git file is used as the foundation for\nlinked worktrees, it's used for other purposes as well and we should\nnot create $X/gitdir in those cases.\n\nTighten the check. Only update an existing file, which is an\nindication this is a linked worktree.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\n---\n setup.c            | 2 +-\n t/t0002-gitfile.sh | 7 +++++++\n 2 files changed, 8 insertions(+), 1 deletion(-)\n\ndiff --git a/setup.c b/setup.c\nindex d343725..b30d923 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -440,7 +440,7 @@ static void update_linked_gitdir(const char *gitfile, const char *gitdir)\n \tstruct stat st;\n \n \tstrbuf_addf(&path, \"%s/gitdir\", gitdir);\n-\tif (stat(path.buf, &st) || st.st_mtime + 24 * 3600 < time(NULL))\n+\tif (!stat(path.buf, &st) && st.st_mtime + 24 * 3600 < time(NULL))\n \t\twrite_file(path.buf, \"%s\", gitfile);\n \tstrbuf_release(&path);\n }\ndiff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh\nindex 9670e8c..b1b59f2 100755\n--- a/t/t0002-gitfile.sh\n+++ b/t/t0002-gitfile.sh\n@@ -99,6 +99,13 @@ test_expect_success 'check rev-list' '\n \ttest \"$SHA\" = \"$(git rev-list HEAD)\"\n '\n \n+test_expect_success '$REAL/gitdir is not created on ordinary git file' '\n+\techo \"gitdir: $REAL\" >expected &&\n+\ttest_cmp expected .git &&\n+\tgit status &&\n+\t! test -f \"$REAL\"/gitdir\n+'\n+\n test_expect_success 'setup_git_dir twice in subdir' '\n \tgit init sgd &&\n \t(\n-- \n2.2.0.513.g477eb31\n"},{"id":"272750","messageId":"CAPig+cTKGtVoNr32C7XfZsKYs3Rhchb1Xrr3YEhJuie1tfa9Vw@mail.gmail.com","threadId":"40660","inReplyTo":"1446491306-13493-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-11-02T20:01:47Z","receivedAt":"2015-11-02T20:01:47Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Nov 2, 2015 at 2:08 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:\n> $X/gitdir is created, or refreshed, in order to keep a linked worktree\n> from being pruned. But while git file is used as the foundation for\n> linked worktrees, it's used for other purposes as well and we should\n> not create $X/gitdir in those cases.\n>\n> Tighten the check. Only update an existing file, which is an\n> indication this is a linked worktree.\n>\n> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\n> ---\n> diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh\n> @@ -99,6 +99,13 @@ test_expect_success 'check rev-list' '\n> +test_expect_success '$REAL/gitdir is not created on ordinary git file' '\n> +       echo \"gitdir: $REAL\" >expected &&\n> +       test_cmp expected .git &&\n> +       git status &&\n> +       ! test -f \"$REAL\"/gitdir\n\nMinor: test_path_is_missing() might convey the intention a bit more clearly.\n\n> +'\n"},{"id":"272752","messageId":"20151102203507.GB10722@sigill.intra.peff.net","threadId":"40660","inReplyTo":"1446491306-13493-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-11-02T20:35:07Z","receivedAt":"2015-11-02T20:35:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 02, 2015 at 08:08:26PM +0100, Nguyễn Thái Ngọc Duy wrote:\n\n> $X/gitdir is created, or refreshed, in order to keep a linked worktree\n> from being pruned. But while git file is used as the foundation for\n> linked worktrees, it's used for other purposes as well and we should\n> not create $X/gitdir in those cases.\n> \n> Tighten the check. Only update an existing file, which is an\n> indication this is a linked worktree.\n\nHrm. I think this fixes the immediate problem, but it seems odd for us\nto rely on \"does the file exist\"[1].\n\nWe trigger this code unconditionally from read_gitfile_gently(). But\n.git files are a general-purpose mechanism.  Shouldn't we be doing this\nonly if we suspect we are working with a linked working tree directory\nin the first place?\n\nOr we do not know at all, because we are operating in the linked dir,\nand seeing the presence of the \"gitdir\" file is the only way we say \"ah,\nit turns out we are linked, so we should take the opportunity to do some\nmaintenance\"?\n\nIf the latter, then I guess this is the only way to do it. It does seem\na bit strange to me that an otherwise read-only operation (reading the\nfile) might involve writing[2].\n\n-Peff\n\n[1] You check only !stat(), so it is not really \"does it exist\", but\n    \"can we stat it\". I think that is OK, because this is an\n    opportunistic update, and failing the stat should just mean we don't\n    do the update.\n\n[2] I suspect this code should use write_file_gently(). What happens if\n    I have a read-only linked checkout?\n"},{"id":"272753","messageId":"xmqqtwp4dt17.fsf@gitster.mtv.corp.google.com","threadId":"40660","inReplyTo":"20151102203507.GB10722@sigill.intra.peff.net","subject":"Re: [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-11-02T20:51:16Z","receivedAt":"2015-11-02T20:51:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> [2] I suspect this code should use write_file_gently(). What happens if\n>     I have a read-only linked checkout?\n\nOr you may not be the owner of the repository, you think you are\ndoing a read-only operation, and you silently end up creating a file\nthat cannot be written by the repository owner?\n\nHonestly, I think this whole \"just in case the user moved without\ntelling us, we sneakily fix things without telling the user\" should\njust go away.  This is not the first incidence of a tool trying to\nbe overly clever and pretend to know better than the end user biting\nus, is it?\n"},{"id":"272755","messageId":"20151102205252.GA12181@sigill.intra.peff.net","threadId":"40660","inReplyTo":"xmqqtwp4dt17.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-11-02T20:52:53Z","receivedAt":"2015-11-02T20:52:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 02, 2015 at 12:51:16PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > [2] I suspect this code should use write_file_gently(). What happens if\n> >     I have a read-only linked checkout?\n> \n> Or you may not be the owner of the repository, you think you are\n> doing a read-only operation, and you silently end up creating a file\n> that cannot be written by the repository owner?\n> \n> Honestly, I think this whole \"just in case the user moved without\n> telling us, we sneakily fix things without telling the user\" should\n> just go away.  This is not the first incidence of a tool trying to\n> be overly clever and pretend to know better than the end user biting\n> us, is it?\n\nI have to admit, that was my gut feeling, too, but I do not know enough\nabout the problem it is solving to say whether it is a good tradeoff.\nUnfortunately 23af91d102e1efaff33b77ab7746356835a3d600 did not have much\ndiscussion. I didn't dig into the mailing list, though. I was hoping Duy\ncould summarize it. :)\n\n-Peff\n"},{"id":"272785","messageId":"CACsJy8Csjgcv_L+TW9YPTs5V=T2XD+eqo1w1PO4jpfDoHLQKpQ@mail.gmail.com","threadId":"40660","inReplyTo":"xmqqtwp4dt17.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-11-03T05:48:31Z","receivedAt":"2015-11-03T05:48:31Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"(resend)\n\nOn Mon, Nov 2, 2015 at 9:51 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> [2] I suspect this code should use write_file_gently(). What happens if\n>>     I have a read-only linked checkout?\n\nI can't hide anything from you guys can I? :) My first attempt was\nmove this update logic back to setup_..._gentle where it should\nbelong, but it got complicated because read_file_gently was buried too\ndeep and there was no easy way to get the information out.\n\nI can try again, or..\n\n>\n> Or you may not be the owner of the repository, you think you are\n> doing a read-only operation, and you silently end up creating a file\n> that cannot be written by the repository owner?\n>\n> Honestly, I think this whole \"just in case the user moved without\n> telling us, we sneakily fix things without telling the user\" should\n> just go away.  This is not the first incidence of a tool trying to\n> be overly clever and pretend to know better than the end user biting\n> us, is it?\n\nThe whole prune strategy is a bit messy trying to cover all cases\nwhile still keeping out of the user's way. Perhaps if we implement\n\"git worktree mv\", or even \"worktree fixup\" so the user can do it\nmanually (back when the prune strategy commit was implemented, there\nwas no git-worktree), then we don't need this magic any more.\n\nSo, which way to go?\n\n-- \nDuy\n"},{"id":"272847","messageId":"xmqqmvuudfk6.fsf@gitster.mtv.corp.google.com","threadId":"40660","inReplyTo":"CACsJy8Csjgcv_L+TW9YPTs5V=T2XD+eqo1w1PO4jpfDoHLQKpQ@mail.gmail.com","subject":"Re: [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-11-03T19:54:33Z","receivedAt":"2015-11-03T19:54:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen <pclouds@gmail.com> writes:\n\n> The whole prune strategy is a bit messy trying to cover all cases\n> while still keeping out of the user's way. Perhaps if we implement\n> \"git worktree mv\", or even \"worktree fixup\" so the user can do it\n> manually (back when the prune strategy commit was implemented, there\n> was no git-worktree), then we don't need this magic any more.\n>\n> So, which way to go?\n\nI'd prefer to see \"conservative and minimal first and carefully\nbuild up\" instead of \"snapping something together quickly and having\nto patch it up in rapid succession before people get hurt.\" and that\nis not limited to the \"worktree\" topic.\n\nI think \"if you move, you are on your own, do not do it.\" would be a\ngood starting point.  The user education material would say: if you\ncreate worktree B out of the primary A, and if you do not like the\nlocation B, you \"rm -fr B\" and then create a new C out of the\nprimary A at a desired place, and do not reuse location B for any\nother purpose.  The list of worktrees kept somewhere in A would then\nname the old location B, and it is OK to notice the staleness and\nremove it, but we do not have to.  At that point, the magic can and\nshould go.\n\nAfter setting the user expectation that way, it is fine to design\nhow we would give \"worktree rm\" and \"worktree mv\".  As long as\nusers' initial expectation is set to \"you do not mv, ever\", these\ncan be introduced without hurting their established use pattern that\nwould involve no 'mv'.\n"},{"id":"275024","messageId":"1451187796-31138-1-git-send-email-pclouds@gmail.com","threadId":"40660","inReplyTo":"xmqqmvuudfk6.fsf@gitster.mtv.corp.google.com","subject":"[PATCH] worktree: stop supporting moving worktrees manually","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-12-27T03:43:16Z","receivedAt":"2015-12-27T03:43:16Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"The current update_linked_gitdir() has a bug that can create \"gitdir\"\nfile in non-multi-worktree setup. Instead of fixing this, we step back a\nbit. The original design was probably not well thought out. For now, if\nthe user manually moves a worktree, they have to fix up \"gitdir\" file\nmanually or the worktree will get pruned. In future, we probably will\nadd \"git worktree mv\" to support this use case.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\n---\n Documentation/git-worktree.txt |  6 ++----\n setup.c                        | 12 ------------\n 2 files changed, 2 insertions(+), 16 deletions(-)\n\ndiff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\nindex 5b9ad04..4814f48 100644\n--- a/Documentation/git-worktree.txt\n+++ b/Documentation/git-worktree.txt\n@@ -33,10 +33,8 @@ The working tree's administrative files in the repository (see\n clean up any stale administrative files.\n \n If you move a linked working tree to another file system, or\n-within a file system that does not support hard links, you need to run\n-at least one git command inside the linked working tree\n-(e.g. `git status`) in order to update its administrative files in the\n-repository so that they do not get automatically pruned.\n+within a file system that does not support hard links, you need to update\n+$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.\n \n If a linked working tree is stored on a portable device or network share\n which is not always mounted, you can prevent its administrative files from\ndiff --git a/setup.c b/setup.c\nindex d343725..6ee2b23 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -434,17 +434,6 @@ static int check_repository_format_gently(const char *gitdir, int *nongit_ok)\n \treturn ret;\n }\n \n-static void update_linked_gitdir(const char *gitfile, const char *gitdir)\n-{\n-\tstruct strbuf path = STRBUF_INIT;\n-\tstruct stat st;\n-\n-\tstrbuf_addf(&path, \"%s/gitdir\", gitdir);\n-\tif (stat(path.buf, &st) || st.st_mtime + 24 * 3600 < time(NULL))\n-\t\twrite_file(path.buf, \"%s\", gitfile);\n-\tstrbuf_release(&path);\n-}\n-\n /*\n  * Try to read the location of the git directory from the .git file,\n  * return path to git directory if found.\n@@ -514,7 +503,6 @@ const char *read_gitfile_gently(const char *path, int *return_error_code)\n \t\terror_code = READ_GITFILE_ERR_NOT_A_REPO;\n \t\tgoto cleanup_return;\n \t}\n-\tupdate_linked_gitdir(path, dir);\n \tpath = real_path(dir);\n \n cleanup_return:\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"275036","messageId":"20151228062206.GA4621@flurp.local","threadId":"40660","inReplyTo":"1451187796-31138-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] worktree: stop supporting moving worktrees manually","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-12-28T06:22:06Z","receivedAt":"2015-12-28T06:22:06Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Dec 27, 2015 at 10:43:16AM +0700, Nguyễn Thái Ngọc Duy wrote:\n> The current update_linked_gitdir() has a bug that can create \"gitdir\"\n> file in non-multi-worktree setup. Instead of fixing this, we step back a\n> bit. The original design was probably not well thought out. For now, if\n> the user manually moves a worktree, they have to fix up \"gitdir\" file\n> manually or the worktree will get pruned. In future, we probably will\n> add \"git worktree mv\" to support this use case.\n> \n> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\n> ---\n> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\n> @@ -33,10 +33,8 @@ The working tree's administrative files in the repository (see\n>  If you move a linked working tree to another file system, or\n> -within a file system that does not support hard links, you need to run\n> -at least one git command inside the linked working tree\n> -(e.g. `git status`) in order to update its administrative files in the\n> -repository so that they do not get automatically pruned.\n> +within a file system that does not support hard links, you need to update\n\nHmm, is this \"hard links\" feature implemented? If not, then this\ndocumentation is a bit outdated.\n\n> +$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.\n\nFollowing the example of af189b4 (Documentation/git-worktree: split\ntechnical info from general description, 2015-07-06), it might be a\ngood idea to keep this high-level overview free of such low-level\ndetails and instead mention $GIT_DIR/worktrees/<id>/gitdir in the\n\"DETAILS\" section.\n\nPerhaps something like this, on top of your patch (assuming that the\n\"hard links\" feature is not implemented):\n\n--- 8< ---\ndiff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\nindex 4814f48..62c76c1 100644\n--- a/Documentation/git-worktree.txt\n+++ b/Documentation/git-worktree.txt\n@@ -32,9 +32,9 @@ The working tree's administrative files in the repository (see\n `git worktree prune` in the main or any linked working tree to\n clean up any stale administrative files.\n \n-If you move a linked working tree to another file system, or\n-within a file system that does not support hard links, you need to update\n-$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.\n+If you move a linked working tree, you need to manually update the\n+administrative files so that they do not get pruned automatically. See\n+section \"DETAILS\" for more information.\n \n If a linked working tree is stored on a portable device or network share\n which is not always mounted, you can prevent its administrative files from\n@@ -135,6 +135,13 @@ thumb is do not make any assumption about whether a path belongs to\n $GIT_DIR or $GIT_COMMON_DIR when you need to directly access something\n inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.\n \n+If you move a linked working tree, you need to update the 'gitdir' file\n+in the entry's directory. For example, if a linked working tree is moved\n+to `/newpath/test-next` and its `.git` file points to\n+`/path/main/.git/worktrees/test-next`, then update\n+`/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next`\n+instead.\n+\n To prevent a $GIT_DIR/worktrees entry from being pruned (which\n can be useful in some situations, such as when the\n entry's working tree is stored on a portable device), add a file named\n--- 8< ---\n"},{"id":"275133","messageId":"CACsJy8ALc32ptP20_Mm+XDRXR6+b=Lam4saV77Kfrr1-3rHjfw@mail.gmail.com","threadId":"40660","inReplyTo":"20151228062206.GA4621@flurp.local","subject":"Re: [PATCH] worktree: stop supporting moving worktrees manually","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-12-29T13:55:54Z","receivedAt":"2015-12-29T13:55:54Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Dec 28, 2015 at 1:22 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n> On Sun, Dec 27, 2015 at 10:43:16AM +0700, Nguyễn Thái Ngọc Duy wrote:\n>> The current update_linked_gitdir() has a bug that can create \"gitdir\"\n>> file in non-multi-worktree setup. Instead of fixing this, we step back a\n>> bit. The original design was probably not well thought out. For now, if\n>> the user manually moves a worktree, they have to fix up \"gitdir\" file\n>> manually or the worktree will get pruned. In future, we probably will\n>> add \"git worktree mv\" to support this use case.\n>>\n>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\n>> ---\n>> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\n>> @@ -33,10 +33,8 @@ The working tree's administrative files in the repository (see\n>>  If you move a linked working tree to another file system, or\n>> -within a file system that does not support hard links, you need to run\n>> -at least one git command inside the linked working tree\n>> -(e.g. `git status`) in order to update its administrative files in the\n>> -repository so that they do not get automatically pruned.\n>> +within a file system that does not support hard links, you need to update\n>\n> Hmm, is this \"hard links\" feature implemented? If not, then this\n> documentation is a bit outdated.\n\nThe prune logic is there. But this hard link is not created by\n'worktree add'. I think calling link() was done at some point but then\nit got dropped. Ah found it, it wasn't a big \"no\" so maybe we can\nrevive it at some point.\n\nhttp://article.gmane.org/gmane.comp.version-control.git/243475\n\n>> +$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.\n>\n> Following the example of af189b4 (Documentation/git-worktree: split\n> technical info from general description, 2015-07-06), it might be a\n> good idea to keep this high-level overview free of such low-level\n> details and instead mention $GIT_DIR/worktrees/<id>/gitdir in the\n> \"DETAILS\" section.\n>\n> Perhaps something like this, on top of your patch (assuming that the\n> \"hard links\" feature is not implemented):\n\nLooks good.\n\nHow about something like this at the end of the last new paragraph?\n\"alternatively if your file system supports hard link and the worktree\nand $GIT_DIR are on the same file system, you can create a hard link\nnamed \"link\" back to the .git file. See gitrepository-layout.txt for\nmore information\".\n\n>\n> --- 8< ---\n> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\n> index 4814f48..62c76c1 100644\n> --- a/Documentation/git-worktree.txt\n> +++ b/Documentation/git-worktree.txt\n> @@ -32,9 +32,9 @@ The working tree's administrative files in the repository (see\n>  `git worktree prune` in the main or any linked working tree to\n>  clean up any stale administrative files.\n>\n> -If you move a linked working tree to another file system, or\n> -within a file system that does not support hard links, you need to update\n> -$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.\n> +If you move a linked working tree, you need to manually update the\n> +administrative files so that they do not get pruned automatically. See\n> +section \"DETAILS\" for more information.\n>\n>  If a linked working tree is stored on a portable device or network share\n>  which is not always mounted, you can prevent its administrative files from\n> @@ -135,6 +135,13 @@ thumb is do not make any assumption about whether a path belongs to\n>  $GIT_DIR or $GIT_COMMON_DIR when you need to directly access something\n>  inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.\n>\n> +If you move a linked working tree, you need to update the 'gitdir' file\n> +in the entry's directory. For example, if a linked working tree is moved\n> +to `/newpath/test-next` and its `.git` file points to\n> +`/path/main/.git/worktrees/test-next`, then update\n> +`/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next`\n> +instead.\n> +\n>  To prevent a $GIT_DIR/worktrees entry from being pruned (which\n>  can be useful in some situations, such as when the\n>  entry's working tree is stored on a portable device), add a file named\n> --- 8< ---\n\n\n\n-- \nDuy\n"},{"id":"275228","messageId":"CAPig+cSDNgSmwMcEKfEQVcY=_7VHFrNiOHkR++YwvPtcsp5WZg@mail.gmail.com","threadId":"40660","inReplyTo":"CACsJy8ALc32ptP20_Mm+XDRXR6+b=Lam4saV77Kfrr1-3rHjfw@mail.gmail.com","subject":"Re: [PATCH] worktree: stop supporting moving worktrees manually","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-12-31T05:59:48Z","receivedAt":"2015-12-31T05:59:48Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Dec 29, 2015 at 8:55 AM, Duy Nguyen <pclouds@gmail.com> wrote:\n> On Mon, Dec 28, 2015 at 1:22 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n>> On Sun, Dec 27, 2015 at 10:43:16AM +0700, Nguyễn Thái Ngọc Duy wrote:\n>>>  If you move a linked working tree to another file system, or\n>>> -within a file system that does not support hard links, you need to run\n>>> -at least one git command inside the linked working tree\n>>> -(e.g. `git status`) in order to update its administrative files in the\n>>> -repository so that they do not get automatically pruned.\n>>> +within a file system that does not support hard links, you need to update\n>>\n>> Hmm, is this \"hard links\" feature implemented? If not, then this\n>> documentation is a bit outdated.\n>\n> The prune logic is there. But this hard link is not created by\n> 'worktree add'. I think calling link() was done at some point but then\n> it got dropped. Ah found it, it wasn't a big \"no\" so maybe we can\n> revive it at some point.\n>\n> http://article.gmane.org/gmane.comp.version-control.git/243475\n\nHmm, yes...\n\n>>> +$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.\n>>\n>> Following the example of af189b4 (Documentation/git-worktree: split\n>> technical info from general description, 2015-07-06), it might be a\n>> good idea to keep this high-level overview free of such low-level\n>> details and instead mention $GIT_DIR/worktrees/<id>/gitdir in the\n>> \"DETAILS\" section.\n>>\n>> Perhaps something like this, on top of your patch (assuming that the\n>> \"hard links\" feature is not implemented):\n>\n> Looks good.\n>\n> How about something like this at the end of the last new paragraph?\n> \"alternatively if your file system supports hard link and the worktree\n> and $GIT_DIR are on the same file system, you can create a hard link\n> named \"link\" back to the .git file. See gitrepository-layout.txt for\n> more information\".\n\nThat makes sense, however...\n\nIf I understand correctly, while it's true that the 'link' file will\ninhibit pruning, don't we still have the problem that \"git worktree\nlist\" will show an outdated path if the user fails to update 'gitdir'?\nAnd doesn't the \"branch already checked out in some other worktree\"\ninterrogation also depend upon 'gitdir' being up-to-date?\n"}]}