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

From: Nico Williams <nico@cryptonector.com>
Date: Jun 25, 2014, 05:29 UTC
Message-ID: <CAK3OfOgb3zt0HKkeQKfMR9u7sKRzjCZAeOQh=qSyt9cVordG4A@mail.gmail.com>
In-Reply-To: <20140624110932.GI14887@thunk.org>

On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o <tytso@mit.edu> wrote:

Show 18 quoted lines

>
> On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
> >
> > 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.

Thanks for pointing this out. Signed tags are objects -- that's a clear and strong precedent.. That's another thing that branches as objects could have: signatures of pushed commits (separately from the commits themselves).

Show 7 quoted lines

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

Shell script, protocol.. The git push protocol is convenient. The fact that git supports a patches-via-email, push, and pull models, that's a great aspect of git. Why disadvantage the push case, when it's so popular (e.g., via github and such)?

Nico --