Re: Bug: Branch Deletion Doesn't Clean Up

From: Jeff King <peff@peff.net>
Date: Feb 4, 2016, 08:17 UTC
Message-ID: <20160204081759.GA23259@sigill.intra.peff.net>
In-Reply-To: <20160204081220.GA11434@glandium.org>

On Thu, Feb 04, 2016 at 05:12:20PM +0900, Mike Hommey wrote:

Show 10 quoted lines

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

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

-Peff