Re: help with distributed workflow/signoff

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Brock,

Brock Peabody wrote:

> Developers wishing to contribute code would push revisions to the gatekeepers'
> repos, who after reviewing the revisions would push them to the Master
> repository, from which developers would have only pull access.
[...]
> This works fine, except for the fact that there is no trail in the master
> repository indicating which GateKeeper approved which revision.
[...]
> I've seen evidence of what we're after - by browsing the repository of git
> itself.  Each revision in it contains an "Author" field and a (frequently
> different) "Committer" field.  Furthermore, there are often multiple
> "Signed-off-by" and "Acked by" logs.  How are these fields populated?

In the Linux kernel and similar projects, there is a sharp distinction
between patch authors and committers[1].  The life cycle of a patch is
something like this:

A patch is written and a rough version is mailed to interested parties.
‘git format-patch’ or ‘git request-pull’ can be useful for this.

The patch is discussed.  Subsystem maintainers, reviewers, testers,
and others try out the patch and form an opinion on whether it is
“cooked” or needs more improvements.  Some of these people (including
the original author) might suggest improved versions of the patch;
each person doing so adds her name to the bottom of the Signed-off-by
list to indicate that to the best of her knowledge the updated patch
is not proprietary but is suitable for inclusion in the project.

At a certain point, the patch is ready.  A committer applies it,
adding appropriate Acked-by etc headers to summarize the discussion
for reference when the code breaks :).  ‘git am -s’ can take care of
adding the sign-off in this case.

The trajectory of the patch afterwards can be tracked through merges.
The commit passes through a hierarchy of maintainers, usually with
the help of ‘git request-pull’.  There is no need to recertify
origin at this point, since the commit object is already set in
stone.

-----

Wait a second.  The patch is never in a git tree until it is fully
cooked?

Well, no, as long as it is made clear, it is perfectly fine to publish
a patch as a commit before it is cooked.  But the relevant git
branches at this point are just a distribution medium, and those
commits are not meant to be pulled by anyone upstream.  Once the
patches seem cooked, a person can _propose_ a branch to be pulled.  If
that branch is completely broken, it is back to the drawing board, and
a new branch is made, usually with the help of ‘git rebase
--interactive’, or ‘git reset’ followed by ‘git add --patch’.

-----

Why not keep the false starts?  Why such concern with history?

To get maximum utility out of ‘git bisect’, it is best if each commit
builds cleanly and the result is not too broken.

To get maximum utility out of ‘git log --grep’ and ‘git log -S’, it
is best if the commit log clearly and logically explains the design
of the current code.

Probably only some of these concerns will apply in your case, but
I thought I should explain the story as well as I could.

Hope that helps,
Jonathan

[1] I am thinking in particular of this message as I write:
http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744