On Tue, Dec 15, 2015 at 8:49 PM, Junio C Hamano <gits...@pobox.com> wrote: > Christian Couder <christian.cou...@gmail.com> writes: > >> +/* >> + * We used to save the location of the work tree and the kernel version, >> + * but it was not a good idea, so we now just save an empty string. >> + */ > > I do agree that storing the kernel version (or hostname or whatever > specific to the machine) was not a good idea. I however suspect > that you must save and check the location of the working tree, > though, for correctness. If you use one GIT_DIR and GIT_WORK_TREE > to do "git add" or whatever, and then use the same GIT_DIR but a > different GIT_WORK_TREE, you should be able to notice that a > directory D in the old GIT_WORK_TREE whose modification time you > recorded is different from the directory D with the same name but in > the new GIT_WORK_TREE, no?
Yeah, if people use many worktrees made using "git worktree", the code above should be fine because there is one index per worktree, but if they just use one GIT_DIR with many GIT_WORK_TREE then there will be only one index used. I am wondering about the case when the worktree is moved and then GIT_WORK_TREE is changed to reflect the new path were the worktree has been moved. In the "git worktree" documentation there is: "If you move a linked working tree to another file system, or within a file system that does not support hard links, you need to run at least one git command inside the linked working tree (e.g. git status) in order to update its administrative files in the repository so that they do not get automatically pruned." It looks like git can detect when a worktree created with "git worktree" has been moved and I wonder if it would be possible to detect if the main worktree pointed to by GIT_WORK_TREE as moved. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
