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? Oleh