Re: [O] Merge branch 'maint'

[Kyle Meyer]

Oleh Krehel <address@hidden> 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