On Jan 14, 2010, at 1:57 AM, Simon Wilkinson wrote:
On 14 Jan 2010, at 02:24, Kurt Zeilenga wrote:
You can't do that with a git merge,
Yes you can. We do in at my day job all the time.
because the commit on HEAD includes the history of everything else on head, which you definitely don't want to pull into the branch.
Individuals commit on their own local clones, and use 'git push' onto the project's trunk. Release engineers can then cherry-pick the trunk patch onto their local clone of the release branch and push to the project's release branch.
That's a cherry-pick, rather than a merge.
Yes, that's what I said.
There's an important difference here - cherry-picks create a completely new object, where as a merge causes the same object to be applied to both branches. Merges make it much easier to see visually what's been applied where, but they do require that you commit to branch, then merge to trunk. Oh, and they only work at all if there's no back, or forwards, porting required.
As the branches will diverge, the process needs to account for porting issues.
I'd also strongly recommend that you take a look at Shawn's "gerrit" tool. This provides a code review tool for patch submission, and hugely simplifies the process of controlling push access to a git tree, and reviewing the changes that you accept.
We've never had any restrictions on commits.
Presumably you don't allow anyone on the internet commit access to the repository!
Never had any restrictions enforced by the repo software (e.g., CVS). We only have system access restrictions, enforced today by who has ssh access or not.
That's the big advantage with gerrit - that it provides a way of managing internet wide commit access. Developers set up ssh keys through a web interface, and can then be given commit access to a project. You can let trusted developers push straight into the tree, and require everyone else to use code review, or you can mandate review for everyone. At OpenAFS, we've found that using gerrit has really increased the pool of people we get code submissions from, as it makes it trivially easy for them to push changes to us. It also massively simplifies the process of reviewing which changes should and shouldn't go in. See http://gerrit.openafs.org/ for our instance, or http://review.source.android.com for the Android one.
I don't see any reason, at least at first, manage access as we do with our CVS repository. Committers get ssh access to the main repo, no git-enforced restrictions. The world gets anonymous access to a read-only clone.
I'm happy to talk to you about OpenAFS's experiences in all of this, if you'd like more details.
Absolutely, thanks for the offer. Up till now my use of git has been extremely basic. It wouldn't bother me too much to continue the CVS-style workflow we've had,
I would strong recommend that one should not change both repo software and engineering process at the same time. First, switch repo software. Learn it. Then, if consider changes the workflow.
Yes - that was pretty much the approach we decided upon. We've kept our cherry-pick based workflow from CVS. The big git change has been that rather than patches going into a bug tracking system for consideration, and then being pulled out of there and pushed into CVS by a small set of commiters, changes now get pushed directly into gerrit by their submitters. This means that, for the commiters, the process of applying the change is a button press or two, which has hugely speeded up our rate of change.
The least change to our processes would be for the random developers (not committers) to submit git patches to our issue tracker which our committers can, upon acceptance, git-am onto their trunk clone and push from their. This is actually just a submission format change, not a change in processes or work-flow.
-- Kurt
-
Kurt Zeilenga