>Learning to Adapt to new DVCS Workflows.

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

The basic problem is when one git change set push contains commits by multiple committers. The foundation does not allow this as depicted in the following diagram from the GIT wiki page:
Basically this is trying to prevent a workflow where non-committers entries show up in the log. All commits have to be done by committers into the central repo. Basically, what eclipse wants is the following:


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

Integrator Workflow:

Dictator Workflow:

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.

Advertisements
This entry was posted in agile, eclipse, git. Bookmark the permalink.

3 Responses to >Learning to Adapt to new DVCS Workflows.

  1. >Great post Dave! The thing I find funny is that the way Git works, you improve tracability since you have the id of the original contributor in the commit logs.At the end of the day, the committers are still responsible for what gets committed to the servers. Nothing stops me today from taking a random patch from somewhere and checking it in.What we need is a tool that helps us make sure we're being responsible. That is where Gerrit comes in. It can record in the commit log who did the push to the blessed repository. And we can customize it to do other things.Time for me to blog. There is a huge reason why git is going to be critical to the future success of Eclipse. And it's the Platform fork that's been brewing for years. At least with git, we can keep that fork in sync. Without it, we're in trouble.

  2. Pat says:

    >Perhaps I'm missing something, but why not have a hook that verifies all authors (committers too? — there's a difference in Git) have competed a contributors agreement or something like that. A simple pre-receive hook could accomplish this quite easily. It doesn't really matter which workflow you use — the blessed repos on eclipse.org can install the hook and any non-conforming commits will never show up.For what it's worth, Gerrit (JGit) doesn't yet support pre-receive hooks. Gerrit has built in support for contributors agreements but I think that only applies to account creation.

  3. David Carver says:

    >@Pat. There is a pre-commit hook, but right now it expects the commit changeset to only contain commits by the person doing the push. So if those commits aren't in the git repo only, and you have commits from multiple committers it rejects the commit. I've suggested your exact change already on the bug. Just verify that all the committs in a change set are for a valid committer or committers for that particular project.Ideally we would use gerrit and the contributor agreement but that is another battle.Eclipse is looking into the situation mentioned in this blog and I suspect us to have a solution soon.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s