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

> 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.
>