Re: help with distributed workflow/signoff
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Jul 14, 2010, 17:24 UTC
- Message-ID
- <AANLkTimdVvKYPQn84IQvk7yxMo-gtrjWWqzN-ypXV78X@mail.gmail.com>
- In-Reply-To
- <loom.20100714T180615-173@post.gmane.org>
On Wed, Jul 14, 2010 at 12:33 PM, Brock Peabody <brock.peabody@gmail.com> wrote:
Show 5 quoted lines
> 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.
Show 8 quoted lines
> 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