On Sun, Mar 11, 2007 at 11:47:22PM -0700, Junio C Hamano wrote: > Thanks. By the way, is it fashionable to misspell "scenario" in > the kernel circles? ;-) Probably not; it's just that many of us are probably fast typists, and there's a race condition between the 'n' and the 'e on the right and left hands, respectively. :-) > > > + git cat-file blob ":1:$path" > "$BASE" 2>/dev/null > > + git cat-file blob ":2:$path" > "$LOCAL" 2>/dev/null > > + git cat-file blob ":3:$path" > "$REMOTE" 2>/dev/null > > + > > + if test -z "$local_mode" -o -z "$remote_mode"; then > > + echo "Deleted merge conflict for $path:" > > + describe_file "$local_mode" "local" "$LOCAL" > > + describe_file "$remote_mode" "remote" "$REMOTE" > > + resolve_deleted_merge > > + return > > + fi > > Running cat-file even when you know it does not exist at that > stage does not feel right here, although you are not checking > the exit status and discarding 2>/dev/null... OK, I'll fix that. > One situation that happens in the real life to cause "we deleted > while they modified" is when in reality we moved then modified > so much that the difference between our version and the common > ancestor version is too large to be considered a rename anymore. > > Such a misidentified rename would appear as one path that is "we > deleted while they modified" (original path) and the other path > that is "we created while they didn't do anything to the path". > The latter does not conflict and is already resolved in the > index when you would run git-mergetool. > > So if you have "we deleted while they modified" conflict, it may > make sense to give the paths the index adds (relative to HEAD), > let the user pick one of them and allow 3-way merge to update > the path we renamed to. The original path which had conflicted > would be removed as the result. I agree that would be useful, but it I'm going to have to restructure the code a bit to support that. Hmm, let me think about that a bit. It occurs to me that I might also want to think about the order in which I present files to be merged to the user in the "git mergetool" case. If we force the user to resolve these cases first, probably in this order: * 2/3-way modified symlink/symlink * The symlink/modified file case * 3-way modified file case * 2-way modified file case (no common ancestor) It also occurs to me that listing all of the files and characterizing them according to what needs to be done up-front might also be a good idea. I can remember, in the pre-git, Bitkeeper days some *truly nasty* ACPI merges where there were some 20-30 files getting renamed and merged at the same time. Blech. Can't we just slap the developers hands when they do something this evil? (Oh right, we already gave the ACPI developers octopus merges which are a bisect nightmare. Sigh... sometimes I'm not sure why we encourage them like this; I guess it makes the kernel have some really test cases for git, which is the only reason why it exists, right? :-) Junio, when and how do you feel about merging this? It's clear the code is going to have to go through some significant changes still to add the above functionality, which would be an argument against merging it, but on the other hand, it's quite useful in its current form and I'd love to get more testers. Another argument in favor of merging it is that we already have more functionality here than hg, monotone, Bitkeeper (as of the last free version), et. al. And hey, I created a man page so that proves I'm going to keep maintaining/improving it. :-) - Ted - 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