On Wed, 18 Apr 2007, Peter Baumann wrote:
On Wed, Apr 18, 2007 at 12:40:10AM -0700, Junio C Hamano wrote:We can do one of two things. I am not sure which one is better. (0) The effect of 'git gc' by definition in the symlink-shared work tree should be the same as in the original repository as the former is to share all the refspace and object database. So we _could_ declare that running 'git gc' in symlink-shared work tree is insane and educate people to run that in the original repository. This is _not_ doing anything. (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.
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.
-- Julian --- Q: How many supply-siders does it take to change a light bulb? A: None. The darkness will cause the light bulb to change by itself. - 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