Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Howver, having .git a file pointing to another git directory allows you to > have locks there. And they can be actually pretty sensible locks, like > > .git/HEAD.<mangled-path> > > actually containing the symbolic ref describing which branch we're on in > that working directory. Likewise, .git/index.<mangled-path> needs to hold > the current index. > > Of course, for this to work, you need to use different HEADs and indexes > only if .git was a file originally. > > BTW <mangled-path> could be a hash of the path, and for convenience, we > could store the path in .git/workdir.<mangled-path>. This I like. Because my day-job coworkers and I make very heavy use of git-new-workdir to manage our compile areas/working directories. :) The biggest problem with new-workdir is the master repository cannot see the HEAD, index or logs/HEAD of the working directories. Consequently it is possible for prune (or repack -a -d) to remove objects that some workdir is still referring to. Its not uncommon for my HEAD reflogs to have stale commits in them. Every once in a while a user looses their HEAD entirely when it gets pruned away, as they had a workdir checked out on a detached HEAD. The second biggest problem is checking out the same branch in two different directories at once. This becomes a problem only if you modify the branch, but still, its a problem. I was thinking that we could add a WORKDIR_HASH to the .git file Lars was proposing. This hash would be the <mangled-path> suffix you are talking about above, and would avoid the need to compute the absolute path for the working directory every time we run a Git command. The hash could be something simple, like the SHA-1 hash of the absolute path at the time of workdir creation. But it would be nice if we could recommend a specific value during workdir creation, so that the WORKDIR_HASH could start with a value that matches something the user would readily recognize. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
