On Fri, Dec 03, 2010 at 03:10:40PM -0500, Eugene Sajine wrote: > Yes this does make sense to me. Although it is not necessary to have > conflicts during the merge - recursive merge as i understand also can > create new blobs. I haven't thought about it too hard, but I don't see why any merge would create a new blob unless there is a conflict. Otherwise you are always taking one of the blobs that already exists in some other part of history. > Now as this is pretty much clear: don't you think that the information > about one blob content changed during the merge should be present in > the merge commit info? No. We suppress "uninteresting" parts of merges by default because they are mostly clutter. If you really want to see them, use "-m". > It seems strange that git log <filename> contains merge commit, but > git whatchanged <filename> doesn't show the merge commit, while this > merge commit actually had a change of content in the file, The fact that git whatchanged does not show merge commits by default is just historical. There is really no need for whatchanged to exist at all these days, now that "git log" can do diffs internally. In fact, it is simply implemented these days as "git log" with a few different defaults. -Peff -- 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