couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 22:11:40 GMT
Not to the thread, I have spun off Dale's excellent point about release
branches into a new thread. I have done this because it doesn't effect this
conversion, and I want to keep us focused on Git workflow.

(It doesn't effect this conversation, because no matter what we decide,
we'll still want to maintain release branches for backporting fixes. The
question is whether these happen at the major point level, or minor point
level.)


On 25 April 2013 23:01, Robert Newson <rnewson@apache.org> wrote:

> Another point in favour of merge commits (non-ff) is that the branch
> merged to leaps forward atomically. It might not be appropriate to see
> the intermediate tree for a feature that consists of multiple commits.
>
> B.
>
> On 25 April 2013 22:59, Robert Newson <rnewson@apache.org> wrote:
> > "I'm not sure where this notion that bisecting with merge
> > commits is harder comes from."
> >
> > From personal experience, but I concede this might point to my
> > deficiency and not git's.
> >
> > On 25 April 2013 22:57, Randall Leeds <randall.leeds@gmail.com> wrote:
> >> 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.
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message