Re: Use case (was Re: Should branches be objects?)

From: Theodore Ts'o <tytso@mit.edu>
Date: Jun 24, 2014, 11:09 UTC
Message-ID: <20140624110932.GI14887@thunk.org>
In-Reply-To: <CAK3OfOgskVKs=eUT+EM+GZOjh0p6gxKeDWH-iTt29P1i1d1iZA@mail.gmail.com>

On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:

Show 8 quoted lines

> 
> Now, suppose that branches were objects.  Then at push time one might
> push with a message about the set of commits being pushed, and this
> message (and time of push, and pusher ID) would get recorded in the
> branch object.  At fetch time the branch objects's histories would be
> pulled (but usually never pushed), and would be available for browsing
> with git log at remotes/<remote>/<branch>.  Each commit of the branch
> object (as it were) would record each logical set of commits.

This seems pretty close to what we have with signed tags. When I send a pull request to Linus, I create a signed tag which createscontains a message about a set of commits, and this message is automatically included in the pull request message generated with "git request-pull", and when Linus merges my pull request, the cryptographically signed tag, along with the message, date of the signature, etc., is preserved for all posterity.

Show 7 quoted lines

> Problem: if pushing via an intermediary the push metadat would get
> lost.  This would argue for either a stronger still notion of related
> commits, or none stronger than what exists now (because ETOOMUCH).
> But this branch object concept could also be just right: if pushing
> through a an intermediary (what at Sun was called a project gate) then
> it becomes that intermedirary's (gatekeeper's) job to squash, rebase,
> regroup, edit, drop, reword, ... commits.

With signed tags, the metadata is preserved even when the set of commits is sent via an intermediary.

It seems the major difference is that it's a pull model, where some projects seem much happier with a push model. But that sounds like what is needed is that someone replaces Linus Torvalds with a shell script --- namely, an e-mail bot that receives pull requests, checks the signed tag against an access control list, and if it is an authorized committer, accepts the pull request automatically (or rejects it if there are merge conflicts).

Not that I am suggesting for even a second that Linus could be fully replaced by a shell script. For example, he handles trivial merge conflicts, and more importantly, applies a "oh my G*d you must be kidding" taste filter on incoming pull requests, which I think would be hard to automate. Then again, neural networks have automatically evolved to recognize cat videos, so we can't rule it out in the future. :-)

Cheers,

							- Ted