Re: [O] Merge branch 'maint'

[Robert Klein]

Hi,

Oleh Krehel <address@hidden> wrote:

> Kyle Meyer <address@hidden> writes:
> 
> > Hello,
> >
> > Oleh Krehel <address@hidden> writes:
> >
> >> Hi all,
> >>
> >> Was the issue of abundant "Merge branch 'maint'" commit messages
> >> discussed before? I couldn't find a reference...
> >>
> >> It's not a big deal, really, but I personally prefer to have linear
> >> history with commits that actually do stuff. And it should be easy
> >> to switch to this style: just use the "rebase" instead of the
> >> "merge" command.
> >>
> >> Anyway, it's a small thing, and if Nicolas or Bastien strongly
> >> like the merge method I won't bring it up again. But if they don't
> >> care either way, I think it's better to start rebasing.
> >
> > While I'm all for rebasing unpushed commits, short-lived feature
> > branches, and throw-away integration branches, your suggestion would
> > frequently rewrite the history of a long-lived public branch.
> 
> Why not just cherry-pick the commits from master onto maint, or the
> other way around? That would result in no merge commits.
> 
> I think it should be possible to rebase two branches without having to
> rewrite the public history. As far as I understood, maint is a subset
> of master, i.e. all commits that are in maint are in master as well.
> Is that correct?

No.

I agree, the many merge commits in August/September look ugly right
after the 8.3/8.3.1 release. Maint and master will surely diverge more,
now...

Best regards
Robert