Re: [PATCH v2 3/3] Add option to transpose parents of merge commit
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:55:27
Johannes Sixt [off-list ref] writes:
Am 11/28/2012 0:00, schrieb Kacper Kornet:quoted
When the changes are pushed upstream, and in the meantime someone else updated upstream branch git advises to use git pull. This results in history: ---A---B---C-- \ / D---EThe commit message will say: Merge branch 'master' of /that/remote * 'master' of /that/remote: E Dquoted
where B is the local commit. D, E are commits pushed by someone else when the developer was working on B. However sometimes the following history is preferable: ---A---D---C'-- \ / '-B-'Better: ---A--D--E--C' \ / `----B
Yup, that topology is what Kacper's workflow wants.
Stepping back a bit, however, I am not sure if that is really true.
The goal of this topic seems to be to keep one integration branch
and always merge *into* that integration branch, never *from* it,
but for what purpose? Making the "log --first-parent" express the
integration branch as a linear series of progress? If so, I suspect
a project with such a policy would dictate that D and E also be on a
side branch, i.e. the history would look more like this:
D---E
/ \
--A-------X---C---
\ /
`-------B
with X being a --no-ff merge of the topic that consists of these two
commits.
In this case, the commit message should say... what? Certainly not the same thing. But I do not see that you changed anything in this regard.
True. If the goal is to emulate a merge of B from a side branch into _the_ integration branch, the summary should also emulate the message that would be given when the remote pulled from your current branch.