Re: [PATCH] t6024: fix timing problem
- From
Junio C Hamano <junkio@cox.net>
- Date
- Dec 12, 2006, 23:23 UTC
- Message-ID
- <7vvekgog0r.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.63.0612122347590.2807@wbgn013.biozentrum.uni-wuerzburg.de>
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...
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.
Show 5 quoted lines
> 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 ;-).