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

[Junio C Hamano <junkio@cox.net>]

Julian Phillips <julian@quantumfyre.co.uk> 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.