Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

quoted text
> 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...

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.

quoted text
> 	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 ;-).



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