On Wed, 3 Jun 2009, Sitaram Chamarty wrote: > > "git merge -s ours" would do precisely the same thing, wouldn't it? Yes. It doesn't matter which way it goes - if a file is seen as being identical (and "none" very much counts) in one parent, it's not judged "interesting" from a merge patch standpoint, or even from a "git log" (aka "revision history") standpoint. > That has happened to me before, and I noticed that git log does not > show the deletion, but rationalised it as being because I had > explicitly done a "-s ours". > > Fixing this would fix that (maybe more common) case too, and show that > the merge commit removed the file. The problem is that quite often, a merge that removes a file _is_ the correct thing when it was removed in one branch, and a merge that adds a file is even more common, and in no way special. We don't show the whole diff in a merge, because the whole diff is often nonsensical (ie so trivial that showing it all just hides the parts that are actually relevant). So I'll have to think about it a bit more. We clearly don't generate good diffs for file deletion/creation in merges, and we should improve on it, but it's definitely not a trivial issue either. Linus -- 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