Re: equal-tree-merges as way to make rebases fast-forward-able

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

 



Quoting Junio C Hamano <gitster@xxxxxxxxx>

> To avoid that, I think (1) the marker has to be more reliable than just
> "happens to have the same tree", and (2) the traversal done by Porcelains
> (your patches 3 thru 5) by default should be unaware of eqt.
>
> I don't know what a suitable marker should look like, though.  The marker
> must be easily identifiable by the lowest level rev-list machinery, so it
> needs to be a sign left somewhere in the commit object.  Perhaps making it
> require to have the same tree as all its parents _and_ a well-known marker
> string in the log message (and nothing else) would be a good start.

I think you can record a merge commit that has an unusual 
list of parents for this. For example, you can record the 
latest version twice, as the first and the second parents, 
and make the previous version the third parent. Because 
such a merge can't be created with git-merge command, you 
can reliably tell that it is an unusual 'marker' merge.

No matter what techinique is used to mark the special 
'marker', if it happens in real life for two or more people 
who worked independantly to arrive at the same conclusion, 
I don't think dismissing it as 'by chance' and discarding 
the contribution from the second branch is a good solution. 
If git is meant to work smoothly in projects where more than 
one person see and accept patches from the same origin, the 
condition is not met 'by chance'; the tool is by design 
supposed to handle it as a regular situation.

On the other hand, if you made the marker reliable, I think 
you don't have to disable this feature by default like you 
said in your (2).

As a side note, I have a bug to report. I tried this sequence 
of commands to make sure git-merge doesn't record the same 
parent twice (the last git-merge is made on the slave branch 
and tries to have slave, master and slave as its three 
parents).

 % git init
 % echo hello >world
 % git add . ; git commit -m first
 % echo again >world
 % git commit -a -m master
 % git checkout -b slave master^
 % echo again >world
 % git commit -a -m slave
 % git merge master slave

But I got the "usage: ..." error message from git-merge.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/


--
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]