Re: [PATCH v2 3/3] Add option to transpose parents of merge commit

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 28, 2012, 16:52 UTC
Message-ID: <7vr4ndhdp7.fsf@alter.siamese.dyndns.org>
In-Reply-To: <50B5B599.3020105@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 30 quoted lines

> Am 11/28/2012 0:00, schrieb Kacper Kornet:
>> 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---E
>
> The commit message will say:
>
>   Merge branch 'master' of /that/remote
>
>   * 'master' of /that/remote:
>     E
>     D
>
>> 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.