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

From: Adam Brewster <adambrewster@gmail.com>
Date: Jul 4, 2008, 02:04 UTC
Message-ID: <c376da900807031904y6309a179u5525f147ebc4cd53@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0807040237580.2849@eeepc-johanness>

Show 7 quoted lines

>>
>> How does everybody feel about the following:
>>
>> - Leave git-basis as a small perl script.
>
> I'd rather not.
>

I'm not exactly sure what your objection is here, but I guess it's either you don't want a separate tool called git-basis that does all of the things I've described, or you don't like my choice of perl to do the work.

If the former, I suggest that my approach is consistent with the philosophy of doing one thing and doing it well. I acknowledge that it could do it's one job better (see potential improvements in my last email), but that doesn't seem to be your complaint.

If the latter, I wonder what practical advantage comes from redoing what I've already done in C. It would be slightly faster, but I'm not worried about saving a few milliseconds in a process that takes at least a couple of minutes (considering of course the time it takes to walk to whatever remote system).

Show 8 quoted lines

>> - Add a -b/--basis option in git-bundle that calls git-basis.  Any
>>   objects mentioned in the output would be excluded from the bundle.
>>   Multiple --basis options will call git-basis once with several
>>   arguments to generate the intersection of specified bases.
>
> So the only function of -b would be to fork() && exec() a _shell_ script?
> I don't like that at all.
>

Not quite.  It would be more like a shortcut for

git-basis --show basis | git-bundle create bundle -all --stdin or git-bundle create bundle --all <( git-basis --show basis )

(the latter of which of course wouldn't work because git-basis doesn't take filenames.

The bundle creation is still done by git-bundle. git-basis is just deciding what should (not) be included in the bundle.

It seems like similar architectures have been accepted to support the -i/--interactive options or git-add and git-rebase.

Show 9 quoted lines

>> - (maybe) Add an option "--update-bases" to automatically call git-basis
>>   --update after the bundle is created successfully.
>
> Rather, have it as a feature to auto-detect if there is a ".basis" file of
> the same basename (or, rather ".state", a I find "basis" less than
> descriptive), and rewrite it if it was there.
>
> It could be forced by a to-be-introduced "--state" option to git-bundle.
>

Just because I'm creating a bundle, doesn't guarantee that the bundle will be installed on any particular remote system, so I think that updating the basis without being told to do so by the user is a bad idea. For example, when creating a bundle, I find it's best to exclude objects that I know exist on ALL of my systems, so that I can pull from it anywhere, but usually I only end up sending it to one system.

With regard to the use of the word basis, it comes from the documentation of git-bundle. It's been a while since I took linear algebra, but if I remember correctly, a basis is a set of vectors that describe a vector space, such that a combination of those vectors yields any point in the space. The analogy isn't perfect, but I think it's pretty close. The word state seems very generic, as the state of a repository includes much more than a list of objects that are known to be available.

Show 5 quoted lines

>> There's still plenty of potential for improvements, like a --gc mode
>> to clean up basis files,
>
> umm, why?  "rm" is not simple enough?
>

rm leaves the files a little cleaner than I'd like. A basis is really a list of objects. --gc should make sure that the objects in the list actually exist, and aren't redundant (if I know that a remote system has a given commit, I also know that it has all of the ancestors, so I could delete them from the basis file without losing (much) information.

Show 5 quoted lines

>> a --rewind option to undo an incorrect --update,
>
> Rather hard, would you not think?  The information is either not there, or
> you store loads of cruft in the .state file.
>

There's some information that you might describe as cruft. It is specifically engineered to enable this operation, and the purpose of --gc is to reduce the volume of that cruft.

>> or improvements in the way it calculates intersections,
>
> Umm.  How so?
>

In a tree with three commits, where A (the root) is a parent of X and Y, if only ommit X is in basisX and only commit Y is in basisY, then the intersection of basisX and basisY should include A. Currently git-basis will return nothing, because it doesn't care about ancestry.

I don't consider this a serious flaw, because it results in extra information being included in the bundle, but should never cause broken bundles that are missing information.

Show 7 quoted lines

>> but I think that with these changes the system is as simple as possible
>> while maximizing flexibility, utility, and usability.
>
> I am not convinced.  This sort of feature belongs into git-bundle.  It
> certainly does not deserve being blessed by yet-another git-* command,
> when we are constantly being bashed for having _way_ too many _already_.
>

I disagree. I think the --basis option seems like a logical addition to git-bundle, but I don't think git-bundle is the right interface to update the basis files.

In other news, it seems, the change to make git-bundle accept --stdin is less controversial, so I'll submit that as a small patch.

> Ciao,
> Dscho
>
>

Adam Brewster