Re: [PATCH] t6024: fix timing problem

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

hI,

On Tue, 12 Dec 2006, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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