>In the Web Tools Incubator on the XQuery Project we just ran into a small snag with the Eclipse restrictions on how items arrive in the official Git repository. This is being discussed in bug 324768, and I think it’s worthy of review by any committer or project that is planning to use git.
This unfortunately prevents two committers from sharing their git repos with each other, collaborating together on a particular bug fix, and then having one of them push the change. There are two ways this pattern can work. (Images provided by Pro Git).
In this particular case, the Integrator workflow was more relevant, as you had two committers that worked on code in their own repos, pulled code from each others repos, and then had one of the committers push the changes back.
Now with git there are ways around this particular issue, but you loose the change log of who did what when the changes are pushed back, and from the bug report and the GIT wiki page the IP concerns are what are driving the current restriction.
So here is a proposal:
Loosen the restriction a bit. If the change set is being pushed in from a committer that has multiple commits, and all the commit email addresses and authors are committer’s email address, then allow the commit. The push still has to be verified through the SSH or verification of the password by the person making the push. It also prevents the public from being able to push the change.
As for the issue with the public. If IP is of concern, enforce the following (which should in my opinion be done anyways), require the commit to have a reference to the Bugzilla entry. Something like:
bug 324768 – Remove Restriction….
* Commit to fix restriction issue
This way you can track back to a relevant bug where the change came from and hopefully why. Now it doesn’t solve the concern of IP, but it does allow committers more freedom to collaborate with each other. Plus it gives you an audit trail back to a relevant public bug where hopefully discussion has taken place.
Git allows so many different ways to work, we aren’t locked into the old Central Repository workflow pattern any longer:
Where does Gerritt fall into this:
Basically as I understand it, Gerritt is acting like the Dictator/Integrator. The code is pushed into one repo, and then is blessed into the blessed repository once appropriate sign offs occur. This could be a possible work around as well, but currently Gerritt is not available at eclipse for other projects.
We need to make sure that we address the concerns of the Foundation and it’s members, but we also need to allow the committers to work the best way they can and not enforce restrictions on them that lead to frustrations.