Re: git-merge-recursive, was Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
- From
Junio C Hamano <junkio@cox.net>
- Date
- Oct 21, 2006, 02:17 UTC
- Message-ID
- <7v4ptyjttb.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.63.0610210359040.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 11 quoted lines
> On Fri, 20 Oct 2006, Linus Torvalds wrote: > >> Git just slurps in all three trees. I actually think that the current >> merge-recursive.c does it the stupid way (ie it expands all trees >> recursively, regardless of whether it's needed or not), but I should >> really check with Dscho, since I had nothing to do with that code. > > AFAIR yes, it does the dumb thing, namely it does not take advantage of > trees being identical when their SHA1s are identical. > > This will be a _tremendous_ speed-up.
While we are talking about merge-recursive, I could use some help from somebody familiar with merge-recursive to complete the read-tree changes Linus mentioned early this month.
The issue is that we would want to remove one verify_absent() call in unpack-tree.c:threeway_merge(). When read-tree decides to leave higher stages around, we do not want it to check if the merge could clobber a working tree file, because having an unrelated file at the same path in the working tree sometimes is and sometimes is not a conflict, depending on the outcome of the merge, and that part of the code does not _know_ the outcome yet.
What this means is that we would need to have the equivalent check in the merge strategy that uses read-tree for three-way merge when we remove this overcautious safety check from read-tree. I've adjusted merge-one-file to do so, but not many people use 'resolve' strategy these days, and we would need the matching change in merge-recursive.
If you are interested, you can see the details in commit 0b35995.