Oleh Krehel <ohwoeo...@gmail.com> writes: > Why not just cherry-pick the commits from master onto maint, or the > other way around? That would result in no merge commits.
The result of doing that is IMO worse than many merge commits. For each fix in maint, you'd end up with two commits that are linked only by a patch id (if there are no conflicts) and perhaps a reference in the message (e.g., if -x is used and there are no conflicts). Merging allows you to manage a large set of changes, including conflicts, between upstream and downstream branches and to be sure about which commits a branch contains. I think cherry picking should be limited to one-off cases where a fix lands in master and then it is later realized that it's needed in maint. > I think it should be possible to rebase two branches without having to > rewrite the public history. A rebase involving public commits will rewrite the public history (except for the useless case where calling "git rebase" does nothing because the branch is already up-to-date). > 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? Yes. As long as there aren't any new commits on maint that have yet to be merged, running $ git log master..maint will return empty and $ git log --oneline --no-merges maint..master will show all commits new to master. -- Kyle