{"thread":{"id":"45020","subject":"init --separate-git-dir does not set core.worktree","startedAt":"2017-02-02T03:55:36Z","lastAt":"2017-02-08T16:41:31Z","messageCount":7,"participants":["Kyle Meyer","Duy Nguyen","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310699","messageId":"87h94d8cwi.fsf@kyleam.com","threadId":"45020","inReplyTo":null,"subject":"init --separate-git-dir does not set core.worktree","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2017-02-02T03:55:25Z","receivedAt":"2017-02-02T03:55:36Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"Hello,\n\nAs of 6311cfaf9 (init: do not set unnecessary core.worktree,\n2016-09-25), \"git init --separate-git-dir\" no longer sets core.worktree\n(test below). Based on the commit message and the corresponding thread\n[1], I don't think this change in behavior was intentional, but I wasn't\nable to understand things well enough to attempt a patch.\n\nThanks.\n\n[1] https://public-inbox.org/git/CALqjkKZO_y0DNcRJjooyZ7Eso7yBMGhvZ6fE92oO4Su7JeCeng@mail.gmail.com/T/#u\n\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex b8fc588b1..444e75865 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -309,6 +309,7 @@ test_expect_success 'init with separate gitdir' '\n \tgit init --separate-git-dir realgitdir newdir &&\n \techo \"gitdir: $(pwd)/realgitdir\" >expected &&\n \ttest_cmp expected newdir/.git &&\n+\tcheck_config realgitdir false \"$(pwd)/newdir\" &&\n \ttest_path_is_dir realgitdir/refs\n '\n \n"},{"id":"310721","messageId":"CACsJy8AZUBt76ZocS2JEr9FP_8Obv8L911AvZxE_sww3qXB7qw@mail.gmail.com","threadId":"45020","inReplyTo":"87h94d8cwi.fsf@kyleam.com","subject":"Re: init --separate-git-dir does not set core.worktree","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-02-02T09:31:48Z","receivedAt":"2017-02-02T09:32:23Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer wrote:\n> Hello,\n>\n> As of 6311cfaf9 (init: do not set unnecessary core.worktree,\n> 2016-09-25), \"git init --separate-git-dir\" no longer sets core.worktree\n> (test below). Based on the commit message and the corresponding thread\n> [1], I don't think this change in behavior was intentional, but I wasn't\n> able to understand things well enough to attempt a patch.\n\nI'm missing some context. Why does --separate-git-dir have to set\ncore.worktree? What fails for you exactly?\n\n>\n> Thanks.\n>\n> [1] https://public-inbox.org/git/CALqjkKZO_y0DNcRJjooyZ7Eso7yBMGhvZ6fE92oO4Su7JeCeng@mail.gmail.com/T/#u\n>\n> diff --git a/t/t0001-init.sh b/t/t0001-init.sh\n> index b8fc588b1..444e75865 100755\n> --- a/t/t0001-init.sh\n> +++ b/t/t0001-init.sh\n> @@ -309,6 +309,7 @@ test_expect_success 'init with separate gitdir' '\n> git init --separate-git-dir realgitdir newdir &&\n> echo \"gitdir: $(pwd)/realgitdir\" >expected &&\n> test_cmp expected newdir/.git &&\n> + check_config realgitdir false \"$(pwd)/newdir\" &&\n> test_path_is_dir realgitdir/refs\n> '\n>\n\n\n\n-- \nDuy\n"},{"id":"310731","messageId":"87efzg7oq3.fsf@kyleam.com","threadId":"45020","inReplyTo":"CACsJy8AZUBt76ZocS2JEr9FP_8Obv8L911AvZxE_sww3qXB7qw@mail.gmail.com","subject":"Re: init --separate-git-dir does not set core.worktree","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2017-02-02T12:37:40Z","receivedAt":"2017-02-02T12:37:49Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"Duy Nguyen writes:\n\n> On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer wrote:\n>>\n>> As of 6311cfaf9 (init: do not set unnecessary core.worktree,\n>> 2016-09-25), \"git init --separate-git-dir\" no longer sets core.worktree\n>> (test below). Based on the commit message and the corresponding thread\n>> [1], I don't think this change in behavior was intentional, but I wasn't\n>> able to understand things well enough to attempt a patch.\n>\n> I'm missing some context. Why does --separate-git-dir have to set\n> core.worktree? What fails for you exactly?\n\nSorry for not providing enough information. I haven't run into a\nfailure.\n\nIn Magit, we need to determine the top-level of the working tree from\nCOMMIT_EDITMSG. Right now that logic [*1*] looks something like this:\n\n * COMMIT_EDITMSG in .git/modules//: set working tree to the\n output of \"git rev-parse --show-toplevel\"\n\n * COMMIT_EDITMSG in .git/worktrees//: set working tree to the\n path in .git/worktrees//gitdir, minus the trailing \"/.git\"\n\n * COMMIT_EDITMSG in .git: set working tree to the parent directory\n\nThis fails for a repo set up with --separate-git-dir [*2*], where the\nlast step will go out into an unrelated repo. If core.worktree was set\nand \"git rev-parse --show-toplevel\" returned the working tree like it\ndid for submodules, things would work.\n\nOf course, the issue above isn't a reason that --separate-git-dir should\nset core.worktree, but the submodule behavior is why we were wondering\nif it should. And so I was going to ask here whether core.worktree\nshould be set, but then I confused myself into thinking 6311cfaf9\nunintentionally changed this behavior.\n\n\n[*1*] This is done by magit-toplevel:\n https://github.com/magit/magit/blob/e34f4e8eb00f292e8c475489fa7caa286857a421/lisp/magit-git.el#L400\n\n[*2*] https://github.com/magit/magit/issues/2955\n https://github.com/magit/magit/issues/2981\n"},{"id":"310806","messageId":"CACsJy8C=owNPpND4Ab7bFE24kpWBr5fQdob21DEDCckCXu0Mng@mail.gmail.com","threadId":"45020","inReplyTo":"87efzg7oq3.fsf@kyleam.com","subject":"Re: init --separate-git-dir does not set core.worktree","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-02-03T13:38:29Z","receivedAt":"2017-02-03T13:39:06Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 2, 2017 at 7:37 PM, Kyle Meyer wrote:\n> Duy Nguyen writes:\n>\n>> On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer wrote:\n>>>\n>>> As of 6311cfaf9 (init: do not set unnecessary core.worktree,\n>>> 2016-09-25), \"git init --separate-git-dir\" no longer sets core.worktree\n>>> (test below). Based on the commit message and the corresponding thread\n>>> [1], I don't think this change in behavior was intentional, but I wasn't\n>>> able to understand things well enough to attempt a patch.\n>>\n>> I'm missing some context. Why does --separate-git-dir have to set\n>> core.worktree? What fails for you exactly?\n>\n> Sorry for not providing enough information. I haven't run into a\n> failure.\n>\n> In Magit, we need to determine the top-level of the working tree from\n> COMMIT_EDITMSG. Right now that logic [*1*] looks something like this:\n\nThis is much better :)\n\n> * COMMIT_EDITMSG in .git/modules//: set working tree to the\n> output of \"git rev-parse --show-toplevel\"\n>\n> * COMMIT_EDITMSG in .git/worktrees//: set working tree to the\n> path in .git/worktrees//gitdir, minus the trailing \"/.git\"\n>\n> * COMMIT_EDITMSG in .git: set working tree to the parent directory\n>\n> This fails for a repo set up with --separate-git-dir [*2*], where the\n> last step will go out into an unrelated repo. If core.worktree was set\n> and \"git rev-parse --show-toplevel\" returned the working tree like it\n> did for submodules, things would work.\n\nOK. If I read this right, given a path of any text file somewhere\nwithin \".git\" directory. you are tasked to find out where the\nassociated worktree is? I.e. this is not an emacsclient executed as\npart of \"git commit\", correct?\n\nSo you need some sort of back-link to \".git\" location. And\nunfortunately there's no such thing for .git file (unless it points to\n.git/worktrees/...). I'm hesitant to set core.worktree unless it's\nabsolutely needed since it may have unexpected interaction with\n$GIT_WORK_TREE and others (not sure if it has any interaction with\nsubmodules too). I think adding a new file \"gitdir\" would be a safer\noption.\n\nI'm not entirely sure if enforcing \"one worktree - one repository\" is\nsafe though. The first two bullet points are very specific and we can\nassume that, but \".git\" files alone can be used for anything. In\ntheory you can always create a secondary worktree (that's not managed\nby \"git worktree\") by setting GIT_WORK_TREE and \"git checkout -f\"\nsomewhere. But I guess those would be temporary and nobody would want\nmagic to point back to them.\n\nAs a fall-back mechanism, I think after magit has found the worktree,\nit should verify the found location is the correct worktree, with \"git\nrev-parse --git-dir\" or something, and alert the user otherwise. I\nthink \"git rev-parse --git-path COMMIT_MSG\" should give back the same\nCOMMIT_MSG path (and it applies for any files in .git dir, covering\nall three cases). The user could add some magit-specific files to tell\nmagit where the actual worktree is when they hit corner cases.\n\nIf the use case is limited to editing COMMIT_EDITMSG only (after it's\ngenerated by git), it may be best to add `pwd` as a comment to that\nfile. You won't have to go through all the magic rules to find it out\n(*). And it helps non-magic users too.\n\n(*) well, you do, because you probably can't expect everybody to have\nlatest git version.\n\n> Of course, the issue above isn't a reason that --separate-git-dir should\n> set core.worktree, but the submodule behavior is why we were wondering\n> if it should.\n\nI'm not a submodule person, so I'll pass that \"why\" question to Stefan.\n\n> And so I was going to ask here whether core.worktree\n> should be set, but then I confused myself into thinking 6311cfaf9\n> unintentionally changed this behavior.\n>\n>\n> [*1*] This is done by magit-toplevel:\n> https://github.com/magit/magit/blob/e34f4e8eb00f292e8c475489fa7caa286857a421/lisp/magit-git.el#L400\n>\n> [*2*] https://github.com/magit/magit/issues/2955\n> https://github.com/magit/magit/issues/2981\n-- \nDuy\n"},{"id":"310863","messageId":"877f55r0mk.fsf@kyleam.com","threadId":"45020","inReplyTo":"CACsJy8C=owNPpND4Ab7bFE24kpWBr5fQdob21DEDCckCXu0Mng@mail.gmail.com","subject":"Re: init --separate-git-dir does not set core.worktree","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2017-02-04T23:34:43Z","receivedAt":"2017-02-04T23:34:51Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"Duy Nguyen writes:\n\n> On Thu, Feb 2, 2017 at 7:37 PM, Kyle Meyer wrote:\n\n[...]\n\n>> * COMMIT_EDITMSG in .git/modules//: set working tree to the\n>> output of \"git rev-parse --show-toplevel\"\n>>\n>> * COMMIT_EDITMSG in .git/worktrees//: set working tree to the\n>> path in .git/worktrees//gitdir, minus the trailing \"/.git\"\n>>\n>> * COMMIT_EDITMSG in .git: set working tree to the parent directory\n>>\n>> This fails for a repo set up with --separate-git-dir [*2*], where the\n>> last step will go out into an unrelated repo. If core.worktree was set\n>> and \"git rev-parse --show-toplevel\" returned the working tree like it\n>> did for submodules, things would work.\n>\n> OK. If I read this right, given a path of any text file somewhere\n> within \".git\" directory. you are tasked to find out where the\n> associated worktree is?\n\nRight\n\n> I.e. this is not an emacsclient executed as part of \"git commit\",\n> correct?\n\n... but it is from a \"git commit\" call. I think you're asking because,\nif we know where \"git commit\" was called from, we know what the working\ntree is. This is true, but with the current Magit design, the function\nfor determining the top-level of the working tree, magit-toplevel,\ndoesn't have access to this information. From Emacs, Magit calls \"git\ncommit\", setting GIT_EDITOR for that process so that git invokes the\ncurrent Emacs instance for editing the commit message. From\nCOMMIT_EDITMSG, we want the magit-toplevel to be able to determine the\nworking tree location so that commands can use magit-toplevel to set\ntheir pwd.\n\nThe only Magit command that currently relies on magit-toplevel to\ndetermine the working tree from \".git/COMMIT_EDITMSG\" is a command that\nshows a diff with the staged changes in a separate buffer. (Even though\n\"git diff --cached\" would work from within \".git/\", some functionality\nin this buffer depends on its pwd being set top-level of the working\ntree.)\n\nSo, whatever solution we come up with on the Magit end will likely\ninvolve recording where \"git commit\" was called so that the diff command\ncan figure out the working tree.\n\n> So you need some sort of back-link to \".git\" location. And\n> unfortunately there's no such thing for .git file (unless it points to\n> .git/worktrees/...). I'm hesitant to set core.worktree unless it's\n> absolutely needed since it may have unexpected interaction with\n> $GIT_WORK_TREE and others (not sure if it has any interaction with\n> submodules too). I think adding a new file \"gitdir\" would be a safer\n> option.\n>\n> I'm not entirely sure if enforcing \"one worktree - one repository\" is\n> safe though. The first two bullet points are very specific and we can\n> assume that, but \".git\" files alone can be used for anything. In\n> theory you can always create a secondary worktree (that's not managed\n> by \"git worktree\") by setting GIT_WORK_TREE and \"git checkout -f\"\n> somewhere. But I guess those would be temporary and nobody would want\n> magic to point back to them.\n\nRight, makes sense.\n\nUnfortunately, magit-toplevel was designed thinking that the\n--separate-git-dir / core.worktree behavior in Git 2.8.4 and lower was\nintentional [*]. We'll need to rework this on our end.\n\nThanks for your input and for confirming that \"git init\n--separate-git-dir\" does not set core.worktree by design.\n\n[*] https://github.com/magit/magit/issues/460#issuecomment-36035787.\n\n-- \nKyle\n"},{"id":"311067","messageId":"CAGZ79kZm7y_gcG-DcjywXzNk9RhPLLkVhjrsLQHijb-DQhnOJw@mail.gmail.com","threadId":"45020","inReplyTo":"877f55r0mk.fsf@kyleam.com","subject":"Re: init --separate-git-dir does not set core.worktree","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-08T16:14:37Z","receivedAt":"2017-02-08T16:17:03Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> [*] https://github.com/magit/magit/issues/460#issuecomment-36035787.\n\nI would agree with the thinking in that issue.\n"},{"id":"311069","messageId":"CAGZ79kZiEdHbWxo6OEu050EOGSvqX0ardZxxV4dpJYveKt4cGQ@mail.gmail.com","threadId":"45020","inReplyTo":"CACsJy8C=owNPpND4Ab7bFE24kpWBr5fQdob21DEDCckCXu0Mng@mail.gmail.com","subject":"Re: init --separate-git-dir does not set core.worktree","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-08T16:13:11Z","receivedAt":"2017-02-08T16:41:31Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Feb 3, 2017 at 5:38 AM, Duy Nguyen wrote:\n> On Thu, Feb 2, 2017 at 7:37 PM, Kyle Meyer wrote:\n>> Duy Nguyen writes:\n>>\n>>> On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer wrote:\n>>>>\n>>>> As of 6311cfaf9 (init: do not set unnecessary core.worktree,\n>>>> 2016-09-25), \"git init --separate-git-dir\" no longer sets core.worktree\n>>>> (test below). Based on the commit message and the corresponding thread\n>>>> [1], I don't think this change in behavior was intentional, but I wasn't\n>>>> able to understand things well enough to attempt a patch.\n>>>\n>>> I'm missing some context. Why does --separate-git-dir have to set\n>>> core.worktree? What fails for you exactly?\n>>\n>> Sorry for not providing enough information. I haven't run into a\n>> failure.\n>>\n>> In Magit, we need to determine the top-level of the working tree from\n>> COMMIT_EDITMSG. Right now that logic [*1*] looks something like this:\n>\n> This is much better :)\n>\n>> * COMMIT_EDITMSG in .git/modules//: set working tree to the\n>> output of \"git rev-parse --show-toplevel\"\n\n.git/modules// itself is a fully fledged git directory, making use of\nthe core.worktree variable to have the working tree at an \"unusual\" place.\n\n\"git rev-parse --show-toplevel\" is the correct place of the working tree\n\n>>\n>> * COMMIT_EDITMSG in .git/worktrees//: set working tree to the\n>> path in .git/worktrees//gitdir, minus the trailing \"/.git\"\n\n(in worktree/:) \"git rev-parse --show-toplevel\"s output is empty,\nbut the gitdir file exists unlike in the other cases.\n\n>>\n>> * COMMIT_EDITMSG in .git: set working tree to the parent directory\n\n(in .git:) \"git rev-parse --show-toplevel\"s output is empty.\n\n>>\n>> This fails for a repo set up with --separate-git-dir [*2*], where the\n>> last step will go out into an unrelated repo. If core.worktree was set\n>> and \"git rev-parse --show-toplevel\" returned the working tree like it\n>> did for submodules, things would work.\n\nWhen using --separate-git-dir you cannot tell where the working tree is from\nwithin the git dir, despite knowing it has to be *somewhere*:\n\n [core]\n bare = false\n\nSo I would hope we'll set core.worktree again in this case. Otherwise how\nwould we discover the working tree?\n\n>\n> OK. If I read this right, given a path of any text file somewhere\n> within \".git\" directory. you are tasked to find out where the\n> associated worktree is? I.e. this is not an emacsclient executed as\n> part of \"git commit\", correct?\n\nI always assumed core.worktree is precisely that analogy, i.e.\ncore.worktree is the backwards pointer to the .git file (which\nis true coming from a submodule background).\n\n>\n> So you need some sort of back-link to \".git\" location. And\n> unfortunately there's no such thing for .git file (unless it points to\n> .git/worktrees/...). I'm hesitant to set core.worktree unless it's\n> absolutely needed since it may have unexpected interaction with\n> $GIT_WORK_TREE and others (not sure if it has any interaction with\n> submodules too). I think adding a new file \"gitdir\" would be a safer\n> option.\n\nHow would \"gitdir\" (should it be called worktree/workingtree instead?)\nwork together with core.worktree set?\nWould it point at the .git file or the root level of the working tree?\n\n>\n> I'm not entirely sure if enforcing \"one worktree - one repository\" is\n> safe though. The first two bullet points are very specific and we can\n> assume that, but \".git\" files alone can be used for anything. In\n> theory you can always create a secondary worktree (that's not managed\n> by \"git worktree\") by setting GIT_WORK_TREE and \"git checkout -f\"\n> somewhere. But I guess those would be temporary and nobody would want\n> magic to point back to them.\n>\n> As a fall-back mechanism, I think after magit has found the worktree,\n> it should verify the found location is the correct worktree, with \"git\n> rev-parse --git-dir\" or something, and alert the user otherwise. I\n> think \"git rev-parse --git-path COMMIT_MSG\" should give back the same\n> COMMIT_MSG path (and it applies for any files in .git dir, covering\n> all three cases). The user could add some magit-specific files to tell\n> magit where the actual worktree is when they hit corner cases.\n>\n> If the use case is limited to editing COMMIT_EDITMSG only (after it's\n> generated by git), it may be best to add `pwd` as a comment to that\n> file. You won't have to go through all the magic rules to find it out\n> (*). And it helps non-magic users too.\n>\n> (*) well, you do, because you probably can't expect everybody to have\n> latest git version.\n>\n>> Of course, the issue above isn't a reason that --separate-git-dir should\n>> set core.worktree, but the submodule behavior is why we were wondering\n>> if it should.\n>\n> I'm not a submodule person, so I'll pass that \"why\" question to Stefan.\n\nGood question. As said above I always assumed it is the backlink to know where\nthe working tree of the submodule is.\n\nDigging through history I found d75219b4a, which explains why that is:\n\n Since recently a submodule with name has its git directory in the\n .git/modules/ directory of the superproject while the work tree\n contains a gitfile pointing there. To make that work the git directory has\n the core.worktree configuration set in its config file to point back to\n the work tree.\n\nI remember reading this some time ago and wondered what the\n\"to make that work\" implies though and IIRC there was nothing I found by\nexperimentation.\n"}]}