Junio C Hamano <junkio@cox.net> writes: > 2. merge-one-file leaves unmerged index entries. > > Regarding #2, in an earlier message you said something about > "patch to do that was just broken" which I did not understand; I > think your patch I am replying to is doing the right thing. That > case arm is dealing with a path that exists in "our" branch and > the working tree blob should be the same as recorded in the > HEAD, so I did not have to do the unpack-cat-chmod like I did in > mine. Am I simply confused? The only difference is that, from the old tradition, we are supposed to allow the merge to happen in an unchecked-out working tree [*1*]. The version you did and I merged in the master branch breaks that, while the patch I posted keeps that premise. I can throw in my change on top of what is already commited for now to "fix" this, but do we still care about the "merge should succeed in an unchecked-out working tree" rule, or does it not matter anymore these days? One thing is that the check with "git diff" to show diff between half-merged and stage2 after a failed merge does not work very well in a sparsely checked out working tree, because the real change is buried among tons of deletes ("diff --diff-filter=UM" helps, though [*2*]). [Footnote] *1* ... and that is why we special case a non-existent working tree file as if it is clean with the index. After a merge, you would end up with a sparsely checked-out working tree that contains only the files that were involved in the merge. *2* Maybe --diff-filter should always include U in the output, because it is rare and when an unmerged entry exists the user would always want to see it. - 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.htmlReceived on Fri Dec 02 19:25:37 2005
This archive was generated by hypermail 2.1.8 : 2005-12-02 19:25:44 EST