Re: [BUG] git-new-workdir doesn't understand packed refs

From: Junio C Hamano <junkio@cox.net>
Date: Apr 18, 2007, 07:40 UTC
Message-ID: <7v7isajfl1.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070418055215.GA32634@xp.machine.xx>

Peter Baumann <waste.manager@gmx.de> writes:

Show 5 quoted lines

> The problem is, when I created the new workdir, I don't have a file
> .git/packed-refs, so a new workdir was created with a dangling symlink,
> e.g.  workdir/.git/packed-refs -> repo/.git/packed-refs (but the last one
> doesn't exist). As it seems, git gc removes the dangling symlink and
> replaces it with a file.

Yes, packed-refs file is creat-to-temp-and-then-rename, and we will lose the sharing if it is run in the symlink-shared work tree.

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.