Re: Bug: Branch Deletion Doesn't Clean Up

[Mike Hommey <mh@glandium.org>]

On Thu, Feb 04, 2016 at 03:17:59AM -0500, Jeff King wrote:
> On Thu, Feb 04, 2016 at 05:12:20PM +0900, Mike Hommey wrote:
> 
> > > > It seems like git branch -d ascend the hierarchy (up to
> > > > .git/refs/heads/), deleting any empty directories.
> > > 
> > > Yes, though it needs to be coupled with making the branch-creation
> > > process more robust to races (since we might create "refs/heads/foo" in
> > > order to make "refs/heads/foo/bar" while somebody else is deleting it to
> > > get rid of "refs/heads/foo/baz").
> > 
> > Can't we come up with a system that would update packed-refs directly
> > instead of creating files?
> 
> There are a few reasons not to:
> 
>   - it breaks backwards compatibility (unless we continue to create the
>     directory in order to put the dot-lock in it, but then I don't think
>     we've gained anything)

Is that the kind of backwards compatibility that matters, though? I
mean, I won't claim to know all the internals of how refs are used, but
you sound like the theoretical incompatibility would be two different
versions of git racing for update-ref on the same local repository.

Not that it would change anything about the other reasons below.

>   - the usual update method for packed-refs is to take a dot-lock, do a
>     whole-file update, and then atomically rename into place.  That
>     makes writing a ref O(# of refs) instead of O(1), and increases lock
>     contention on the packed-refs file.
> 
>   - if we abandon atomic renames as the update mechanism and just update
>     in place via lseek/write, then we need read-locking, or we need to
>     hope that a reader will never see a sheared write
> 
> But if we're willing to break compatibility, we should ditch packed-refs
> entirely and move to a _real_ concurrent database. And there is work
> underway already to do that (see David Turner's ref-backend-lmdb
> series).

Mike