Re: cannot find hash in the log output

From: Eugene Sajine <euguess@gmail.com>
Date: Dec 3, 2010, 20:10 UTC
Message-ID: <AANLkTim59JP-fuVTeLwxV0bktbdCq04P8XzxVmbu2Qjd@mail.gmail.com>
In-Reply-To: <20101203175212.GA8267@sigill.intra.peff.net>

On Fri, Dec 3, 2010 at 12:52 PM, Jeff King <peff@peff.net> wrote:

Show 21 quoted lines

> On Fri, Dec 03, 2010 at 12:41:52PM -0500, Eugene Sajine wrote:
>
>> > yes. I do see it with your command.
>> >
>> > git ls-tree -r HEAD | grep <resulting SHA1 from git hash-object>
>> >
>> > Thanks,
>> > Eugene
>> >
>>
>> While I'm able to see that object using the command Junio has provided
>> the question remains the same:
>> How could the file get into the state where its hash (git has-object
>> file-name) cannot be found in any commit (git log --raw --no-abbrev |
>> grep SHA1), if there was no local changes made to the file???
>
> If the blob was created as the resolution of a merge conflict, I don't
> think that will appear in the output of "git log --raw".
>
> -Peff
>

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. 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? 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, and finally "git log --raw <filename>" does list the merge commit but is not showing that particular blob had a change and now has a new SHA1?

IMHO everytime there is a change in the content this change should be logged properly.

Thanks, Eugene