On Wed, Apr 18, 2007 at 09:23:14AM -0700, Junio C Hamano wrote: > Julian Phillips <julian@xxxxxxxxxxxxxxxxx> writes: > > >>> (1) We could by convention declare a worktree whose .git/refs > >>> is a symlink, and have git-gc and friends check for it, and > >>> either refuse to run or automatically chdir and run there. > >>> > >>> If we were to do this, we probably should check more than > >>> just .git/refs but some other symlinks under .git/ as well. > >>> > >>> (2) We could dereference .git/packed-refs, when it is a > >>> symlink, by hand, just like we dereference a symlink HEAD > >>> by hand (see resolve_ref() in refs.c), and run the > >>> creat-to-temp-and-then-rename sequence to update the real > >>> file that is pointed at by it. > >>> > >> > >> Its not all the clear which one is the best, but (2) sounds as the most > >> promosing aproach. Hopefully, I'll have time to cook up a patch this > >> evening. > > > > Personally I think (1) might be slightly better, in the refuse to run > > form. gc is a repository operation, not a working directory one - and > > by refusing to run in a workdir this is made clear. You could print > > out a message that includes the location of the actual repo to be more > > friendly though. > > I've seen Peter's patch that attempts to do (2), and I think > that probably is a right direction. A worktree that borrows a > repository from another worktree is trying to allow you to do > as many things you would normally do in the original worktree, > with a caveat: certain things are less safe and/or confusing and > you must know what you are doing if you use such a setting. > > > But whatever solution you go for, you can't use _any_ workdir that > > points at a repo that is having gc run on, either directly or > > indirectly, without risky odd behaviour. > > And I think the above is just one of certain things that are > less safe (one "confusing" is that working on the same branch > would result in gremlin updates). > > There still is an issue of what to do if the .git/packed-refs is > a symlink to a symlink. Peter's patch does a wrong thing, by > creat-then-rename overwriting the symlinked target; at least we > should detect that case and error out, I think. > > Recursively dereferencing the symbolic link by hand to a limit > to avoid infinite recursion (error out when we reach the limit) > would be a more elaborate solution that probably is the right > thing to do. > I thought about the case where packed-refs is a symlink to another symlink and then decided that it's not worth to implement this because a workdir should be linked to a _repo_ and not another workdir. -Peter - 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