Hi, Oleh Krehel <ohwoeo...@gmail.com> wrote:
> Kyle Meyer <k...@kyleam.com> writes: > > > Hello, > > > > Oleh Krehel <ohwoeo...@gmail.com> 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
