Re: help with distributed workflow/signoff

On Wed, Jul 14, 2010 at 12:33 PM, Brock Peabody [off-list ref] wrote:

We've scoured the internet for solutions.  One idea we have tried and abandoned
is using 'git commit -s --amend'. This does create a new revision with the
signoff information we want, but the problem is that it creates a new revision.
Eventually, the developers (and the GateKeeper repository) will end up with both
the revision containing the signoff and one without it.

One option is to avoid trying to signoff each *revision*, but instead
signoff on an entire *batch* of changes.  Basically, the maintainer
would do something like this:

   git checkout master
   git merge --no-ff whateveruser/whateverchanges
   git commit --amend --signoff
   git push

Then the maintainer will have a merge commit that shows he looked at
it.  All the individual sub-patches will remain identical, so nobody's
history gets confused.

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?  Are new
revisions created each time the sign-off information is added? If so, how do the
contributors deal with these new revisions when synchronizing with the master
later?  How are the pre-signoff revisions purged from the bare GateKeeper
repositories?

The way it works in git is that patches are sent in via this mailing
list - the maintainer rarely uses git merge or pull (except to merge
his own branches).  Thus, the "author" is the person who emailed the
patch, and the "committer" is the person who applied the patch to his
own tree.

The result is an elegant looking history, but of course, the committer
generates an entirely different commit id than the author had in his
own history.  Since the maintainer never pulls directly from the
author, it's each author's job to wipe/rebase his own history
occasionally to stay in sync with the "upstream."

For an open source project, where most contributions are by volunteers
and need to have their patches reviewed multiple times before
submission - and frequently, more patchsets are rejected than applied
- this works reasonably well.  For a company where (in my experience
at least) most people's patches *are* applied, and the ratio of
reviewers to coders is much lower, that's much less workable.  And
unfortunately the elegant looking multiple-signed-off-by or acked-by
lines don't work so well for that.

Oh, now that I think of it, you might find git-notes useful.  I've
never used it but I understand it lets you add lines to the log
messages retroactively.  Of course, that can be both a blessing and a
curse.  If you can retroactively change signoffs, the signoffs aren't
that valuable.

Have fun,

Avery