Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Thu, Feb 2, 2017 at 7:37 PM, Kyle Meyer <kyle@xxxxxxxxxx> wrote: [...] >> * COMMIT_EDITMSG in .git/modules/<module>/: set working tree to the >> output of "git rev-parse --show-toplevel" >> >> * COMMIT_EDITMSG in .git/worktrees/<wtree>/: set working tree to the >> path in .git/worktrees/<wtree>/gitdir, minus the trailing "/.git" >> >> * COMMIT_EDITMSG in .git: set working tree to the parent directory >> >> This fails for a repo set up with --separate-git-dir [*2*], where the >> last step will go out into an unrelated repo. If core.worktree was set >> and "git rev-parse --show-toplevel" returned the working tree like it >> did for submodules, things would work. > > OK. If I read this right, given a path of any text file somewhere > within ".git" directory. you are tasked to find out where the > associated worktree is? Right > I.e. this is not an emacsclient executed as part of "git commit", > correct? ... but it is from a "git commit" call. I think you're asking because, if we know where "git commit" was called from, we know what the working tree is. This is true, but with the current Magit design, the function for determining the top-level of the working tree, magit-toplevel, doesn't have access to this information. From Emacs, Magit calls "git commit", setting GIT_EDITOR for that process so that git invokes the current Emacs instance for editing the commit message. From COMMIT_EDITMSG, we want the magit-toplevel to be able to determine the working tree location so that commands can use magit-toplevel to set their pwd. The only Magit command that currently relies on magit-toplevel to determine the working tree from ".git/COMMIT_EDITMSG" is a command that shows a diff with the staged changes in a separate buffer. (Even though "git diff --cached" would work from within ".git/", some functionality in this buffer depends on its pwd being set top-level of the working tree.) So, whatever solution we come up with on the Magit end will likely involve recording where "git commit" was called so that the diff command can figure out the working tree. > So you need some sort of back-link to ".git" location. And > unfortunately there's no such thing for .git file (unless it points to > .git/worktrees/...). I'm hesitant to set core.worktree unless it's > absolutely needed since it may have unexpected interaction with > $GIT_WORK_TREE and others (not sure if it has any interaction with > submodules too). I think adding a new file "gitdir" would be a safer > option. > > I'm not entirely sure if enforcing "one worktree - one repository" is > safe though. The first two bullet points are very specific and we can > assume that, but ".git" files alone can be used for anything. In > theory you can always create a secondary worktree (that's not managed > by "git worktree") by setting GIT_WORK_TREE and "git checkout -f" > somewhere. But I guess those would be temporary and nobody would want > magic to point back to them. Right, makes sense. Unfortunately, magit-toplevel was designed thinking that the --separate-git-dir / core.worktree behavior in Git 2.8.4 and lower was intentional [*]. We'll need to rework this on our end. Thanks for your input and for confirming that "git init --separate-git-dir" does not set core.worktree by design. [*] https://github.com/magit/magit/issues/460#issuecomment-36035787. -- Kyle