couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 21:57:00 GMT
On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson <rnewson@apache.org> wrote:
>
> If we enhance the #1 proposal to include a final rebase against master
> before merge, then master will be truly linear. That will make for
> easier reading, easier backporting and will enable bisecting when
> spelunking for regressions, etc.

I disagree.

git-bisect is smart enough to remove whole merges before diving into
their constituent commits, IIRC, which reduces the possibility of
false negatives if there were intermediate commits that had failing
tests on the feature branch but the ultimate merge was clean and
green. I'm not sure where this notion that bisecting with merge
commits is harder comes from.

Similarly, backporting a topic branch should look something like:

> git checkout -b topic-branch-1.3.x-backport topic-branch
> git rebase --onto 1.3.x master

This would produce a branch (topic-branch-1.3.x-backport) which
contains all the commits on topic-branch since it diverged from
master, rebased onto 1.3.x.

Reading history with merge commits can also be easier than the
alternative FF-only history since there is a --merges option to
git-log. This feature can, for instance, show you time line of topic
introduction without the clutter of the individual commits that were
necessary to produce them.

If I am going to argue one way or another I would actually suggest
that feature or topic branches always merge with --no-ff.

Mime
View raw message