Re: first parent, commit graph layout, and pull merge direction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andreas Krey <a.krey@xxxxxx> writes:

> On Thu, 23 May 2013 09:01:15 +0000, Junio C Hamano wrote:
> ...
>> Instead of having a nice "these six commits marked as 'x' were done
>> on a branch forked some time ago, to address only this one issue and
>> to address it fully" history that explains how these commits were
>> related and these commits are the full solution to a single issue:
>> 
>>       x---x---x---x---x---x
>>      /                     \
>>  ---o---o---o---o---o---o---M---o---o---...
>> 
>> they end up with something like this, even with the "flip the heads
>> of a merge" option, by pulling too often:
>> 
>>       x---x   x---x---x   x
>>      /     \ /         \ / \
>>  ---o---o---M---o---o---M---M---o---o---...
>
> Wouldn't that be (you don't want to put your work back into master before
> it's done) the following?
>
>        x---x---M---x---x---M--x
>       /       /           /    \
>   ---o---o---M---o---o---M--o---M---o---o---...

That is what you would get if you "pull from my upstream" with the
current software.

And that is what triggered this discussion thread in which some
people said that they do not want that shape of the history.

At the leftmost merge M you drew on the upper line (i.e. your
topic), the merge pulls in other's commits that are unrelated to
each other as if it were a meaningful group of commits on a side
branch.  They want to see the merge going other way around, pulling
your work done on a side branch, integrating into the mainline.

The second illustration you are commenting on were done to explain
why such a "when pulling from my upstream, I want the order of
parents swapped, so that mainline appears as the first parent" is
not solving the whole issue.  The time series would go more like
this:

(1) While you were working on two 'x's, others have worked to
    advance the mainline:

       x---x  Your 'master'
      /
  ---o---o  Mainline


(2) You cannot push without losing others work, so you pull, but in
    order to avoid the "others work on mixed on a single side
    branch" issue, you use the fictional "flip heads of a merge"
    option, and push the result out.  That becomes the tip of the
    mainline:

       x---x
      /     \
  ---o---o---M

(3) Then you keep working to build more commits on top. 

       x---x   x---x---x
      /     \ /
  ---o---o---M

(4) And others also keep working.

       x---x   x---x---x
      /     \ /
  ---o---o---M---o---o

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]