openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

On Fri, 2012-05-11 at 17:44 -0700, James E. Blair wrote:
> On 05/11/2012 02:04 PM, Mark McLoughlin wrote:
> > On Fri, 2012-05-11 at 13:57 -0700, David Lutterkort wrote:
> >> On Fri, 2012-05-11 at 12:37 +0100, Mark McLoughlin wrote:
> >>>    - Our history is far from "clean history", it's pretty disgusting
> >>>      really. The ratio of interesting commits to merge commits is
> >>>      roughly 3:2, which is pretty cluttered. With the kernel, it's more
> >>>      like 15:1
> >>
> >> Would a policy of 'non-rebasing branches have to be linear' be too
> >> onerous ? I've never met a merge commit I really liked; it would require
> >> committers to rebase before pushing, but it makes the history much more
> >> useful.
> >
> > I'm guessing we could easily flick a switch in gerrit to cause it to
> > rebase instead of merge.
> 
> Cherry-pick, 

Assuming you have master checked out and you want to pull in the patch
without a merge commit, yes.

But you can also checkout out the patch, rebase it onto master and push
that.

> in this case, but yes.  See this commit for an example of what it
> would look like:
> 
> https://github.com/openstack/openstack-ci-puppet/commit/0d716c1fe1830b47a44541cd0db35248cb52cd87

Looks good.

> > The thing we'd lose is the context of which parent commit a patch was
> > written against.
> 
> Indeed,

What I meant was: when you merge a commit from gerrit, you know what
upstream commit the author based his patch on. So if you find later that
the change caused a problem, you can see whether the problem is as a
result of an upstream change that happened after the author made his
change.

> Gerrit ignores patch dependencies when in cherry-pick mode, so if you
> propose a series of patches, they will not be guaranteed to be merged
> in the correct order.

But that's totally broken, we can't have that happening.

Roll on "topic reviews"!

> Note that the next release of gerrit, to which we are in the process of 
> upgrading, has a "rebase" button in the UI that should make the task of 
> rebasing the current patch set much easier.

Presumably it doesn't try to help you resolve merge conflicts?

Cheers,
Mark.