hI, On Tue, 12 Dec 2006, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > This script tests a complicated merge, where _all_ files conflict. In > > these circumstances, the ordering of the commits -- which is affected > > not by the timestamps in the commit message -- becomes a deciding factor > > of the merge result. > > "not by the timestamps", or "by the timestamps"? I am confused... I deleted the "only", but not the "not" in front of it. Should have read my mail before sending... Sorry. > Do you mean the commit timestamps affect which merge base commit becomes > ours and theirs during the computation of the virtual merge base commit? > That certainly explains the problem. It affects in which order the merge bases are merged. I remember that I made a case for the oldest merge base to go first. If two of them (or all three!) have the same timestamp, I _think_ they are ordered by SHA1... Now, the problem here is that two of the merge bases have a common merge base, but the third has a completely different root. So, depending on which merge base goes first, the add/add conflict can remove the file from the index early, in which case the next merge does not find a stage 1. > > How about this: if there is an add/add conflict, we treat it as > > if there _was_ an empty file, and we let the shiny new xdl_merge() > > find the _true_ conflicts, _instead of_ removing the file from > > the index, adding both files with different "~blabla" markers > > appended to their file names to the working directory. > > I was not thinking about this t6024 test failure problem but was > wondering about doing exactly that in merge-recursive to match > the "two file merge" magic we have in git-merge-one-file.sh --- > I guess great minds do think alike ;-). *beams* Gee, thanks! Ciao, Dscho - 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