openstack team mailing list archive

["James E. Blair" <corvus@xxxxxxxxxxxx>]

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

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

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

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.

-Jim