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 Mon, 29 Apr 2013 13:48:18 GMT
Does anybody have any other thoughts on this? We need to choose something
as soon as possible.


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