Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle

From: Jeff King <peff@peff.net>
Date: Jul 4, 2008, 19:51 UTC
Message-ID: <20080704195110.GA3752@sigill.intra.peff.net>
In-Reply-To: <c376da900807031638l219229bcy983ed994b37512c9@mail.gmail.com>

On Thu, Jul 03, 2008 at 07:38:21PM -0400, Adam Brewster wrote:

Show 5 quoted lines

> There's still plenty of potential for improvements, like a --gc mode
> to clean up basis files, a --rewind option to undo an incorrect
> --update, or improvements in the way it calculates intersections, but
> I think that with these changes the system is as simple as possible
> while maximizing flexibility, utility, and usability.

I was thinking about Mark's approach, and I think there are two distinct differences from yours:

  1. he updates the basis upon bundle creation, rather than as a
     separate step (and I have already commented on this)

  2. he stores the basis in the refs hierarchy

I actually think '2' makes a lot of sense. Storing the basis as refs gets you:

  - an easy implementation; you use existing git tools

  - correct reachability analysis, since the refs will be taken into
    account by git-fsck, meaning you won't ever accidentally prune
    your basis objects

  - free logging of your basis history, in the form of reflogs

  - free gc in the usual reflog way

IIRC, Mark suggested putting them under refs/remotes/<bundle>, and you objected that you didn't want to clutter that hierarchy. If that is a problem, you can always use refs/basis/<bundle>, which will be ignored by gitk and "git branch -a", but will be correctly handled by other tools.

And then suddenly your perl script gets a lot simpler, and is either a short shell script, or even better, can be written in C as part of git-bundle. So you would have something like "git bundle --update-basis <basis>" instead of "git-basis", and a config option like "bundle.autoUpdateBasis" to update the basis whenever you create a bundle.

-Peff