Re: cannot find hash in the log output

From: Jeff King <peff@peff.net>
Date: Dec 3, 2010, 21:11 UTC
Message-ID: <20101203211158.GA2632@sigill.intra.peff.net>
In-Reply-To: <AANLkTim59JP-fuVTeLwxV0bktbdCq04P8XzxVmbu2Qjd@mail.gmail.com>

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