Re: cannot find hash in the log output

[Jeff King <peff@peff.net>]

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