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