Re: [O] Merge branch 'maint'

[Oleh Krehel]

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?

    Oleh