cannot find hash in the log output

cannot find hash in the log output

[Eugene Sajine]

Hi,

I have a strange issue (git v 1.7.3.2). I'm cloning the repository,
navigating to the folder containing some scripts and performing
git hash-object <one_of_my_scripts>

Then I'm trying to run:

git log --raw --no-abbrev | grep <resulting SHA1 from previous command>

And i don't see anything.

How is that possible, considering no local changes to the file has
been done, working directory clean?? How could the file get into this
state?

Thanks,
Eugene

Re: cannot find hash in the log output

[Junio C Hamano]

Eugene Sajine <euguess@gmail.com> writes:

> I have a strange issue (git v 1.7.3.2). I'm cloning the repository,
> navigating to the folder containing some scripts and performing
> git hash-object <one_of_my_scripts>
>
> Then I'm trying to run:
>
> git log --raw --no-abbrev | grep <resulting SHA1 from previous command>
>
> And i don't see anything.

Do you see it in the output from "git ls-tree -r HEAD"?

Re: cannot find hash in the log output

[Eugene Sajine]

On Thu, Dec 2, 2010 at 3:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> I have a strange issue (git v 1.7.3.2). I'm cloning the repository,
>> navigating to the folder containing some scripts and performing
>> git hash-object <one_of_my_scripts>
>>
>> Then I'm trying to run:
>>
>> git log --raw --no-abbrev | grep <resulting SHA1 from previous command>
>>
>> And i don't see anything.
>
> Do you see it in the output from "git ls-tree -r HEAD"?
>


yes. I do see it with your command.

git ls-tree -r HEAD | grep <resulting SHA1 from git hash-object>

Thanks,
Eugene

Re: cannot find hash in the log output

[Eugene Sajine]

On Thu, Dec 2, 2010 at 4:07 PM, Eugene Sajine <euguess@gmail.com> wrote:
> On Thu, Dec 2, 2010 at 3:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Eugene Sajine <euguess@gmail.com> writes:
>>
>>> I have a strange issue (git v 1.7.3.2). I'm cloning the repository,
>>> navigating to the folder containing some scripts and performing
>>> git hash-object <one_of_my_scripts>
>>>
>>> Then I'm trying to run:
>>>
>>> git log --raw --no-abbrev | grep <resulting SHA1 from previous command>
>>>
>>> And i don't see anything.
>>
>> Do you see it in the output from "git ls-tree -r HEAD"?
>>
>
>
> 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???

Thanks,
Eugene

Re: cannot find hash in the log output

[Jeff King]

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

Re: cannot find hash in the log output

[Eugene Sajine]

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

Re: cannot find hash in the log output

[Jonathan Nieder]

Eugene Sajine wrote:

> 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?

"git rev-list <revs> | git diff-tree --root -c --stdin" might give
some joy.

Re: cannot find hash in the log output

[Eugene Sajine]

On Fri, Dec 3, 2010 at 3:29 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Eugene Sajine wrote:
>
>> 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?
>
> "git rev-list <revs> | git diff-tree --root -c --stdin" might give
> some joy.
>

Allright, this is much closer now;) I used

git rev-list HEAD | git diff-tree --root -c --stdin | grep <SHA1 of
blob interest>

(I need to read now about diff-tree)
That gives me the output like this:

::SourceMode1 SourceMode2 resultMode Source1-SHA1 Source2-SHA1
resultingSHA1 MM path/to/file


Now two questions:

1. a) Why this exact output is not provided in "git log --raw" or in
"git whatchanged" for the merge commits? b) Can it be provided?
2. If 1b=no Is this the ultimate final solution to check if the blob
has appeared somewhere in the history?


Thanks!
Eugene

Re: cannot find hash in the log output

[Jonathan Nieder]

Eugene Sajine wrote:

> ::SourceMode1 SourceMode2 resultMode Source1-SHA1 Source2-SHA1 resultingSHA1 MM path/to/file
[...]
> 1. a) Why this exact output is not provided in "git log --raw" or in
> "git whatchanged" for the merge commits? b) Can it be provided?

Sorry to be opaque.  "git log" et al accept -c too, of course. :)  I pointed
to diff-tree because it seems you are scripting, so its simplicity and
better guarantees about long-term compatibility might be appealing.

Cheers,
Jonathan

Re: cannot find hash in the log output

[Eugene Sajine]

On Fri, Dec 3, 2010 at 3:55 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Eugene Sajine wrote:
>
>> ::SourceMode1 SourceMode2 resultMode Source1-SHA1 Source2-SHA1 resultingSHA1 MM path/to/file
> [...]
>> 1. a) Why this exact output is not provided in "git log --raw" or in
>> "git whatchanged" for the merge commits? b) Can it be provided?
>
> Sorry to be opaque.  "git log" et al accept -c too, of course. :)  I pointed
> to diff-tree because it seems you are scripting, so its simplicity and
> better guarantees about long-term compatibility might be appealing.
>
> Cheers,
> Jonathan
>

Wow! that is pretty cool - it is one of the diff options that log
understands... interesting...
Thank you very much!

Eugene

Re: cannot find hash in the log output

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

>> ::SourceMode1 SourceMode2 resultMode Source1-SHA1 Source2-SHA1 resultingSHA1 MM path/to/file
> [...]
>> 1. a) Why this exact output is not provided in "git log --raw" or in
>> "git whatchanged" for the merge commits? b) Can it be provided?
>
> Sorry to be opaque.  "git log" et al accept -c too, of course. :)  I pointed
> to diff-tree because it seems you are scripting, so its simplicity and
> better guarantees about long-term compatibility might be appealing.

Two nits if this is really to help scripters.

 - Both -c and --cc cull merges uninteresting at the file level; if the
   script _really_ wants to view the whole history, giving -m would be
   more appropriate.

 - The default history traversal is --dense and also with merge
   simplification turned on; again, if the script _really_ wants to view
   the whole history, --sparse and/or --full-history would be necessary
   depending on the needs.

Re: cannot find hash in the log output

[Jeff King]

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

Re: cannot find hash in the log output

[Jeff King]

On Fri, Dec 03, 2010 at 04:11:58PM -0500, Jeff King 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.

Er, sorry, this is totally wrong. For some reason I said "conflict"
(repeatedly) when I meant "trivial merge". I guess my brain is not
working today.

Any time you have to do file-level merging (i.e., because both sides
of the merge touched that path) you will create a new blob, conflicts or
no.

-Peff

Re: cannot find hash in the log output

[Jonathan Nieder]

Junio C Hamano wrote:

> Two nits if this is really to help scripters.
> 
>  - Both -c and --cc cull merges uninteresting at the file level; if the
>    script _really_ wants to view the whole history, giving -m would be
>    more appropriate.
> 
>  - The default history traversal is --dense and also with merge
>    simplification turned on; again, if the script _really_ wants to view
>    the whole history, --sparse and/or --full-history would be necessary
>    depending on the needs.

In a "tree blame" script:

 - silence when a file was not changed from at least one parent is
   perfectly appropriate --- that is not the birth of a blob;
 - --dense versus --sparse shouldn't affect the output if the
   rev-list and diff-tree are limited in the same way;
 - history simplification is probably appropriate --- blind alleys
   are not needed to explain the origin of this blob.

On the other hand, a "lifetime of this content" script would have very
different requirements ---

 - changes from all parents would need to be tracked, requiring -m;
 - --dense versus --sparse would still not matter, but:
 - history simplification would be inappropriate, anyway --- blind
   alleys ought to be investigated in case the content made a brief
   appearance some time in the past.

--- making the options you mention quite relevant.  Thanks.