From: Eugene Sajine <euguess@gmail.com>
Date: Fri, 03 Dec 2010 20:10:40 GMT
Subject: Re: cannot find hash in the log output
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:
> 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