cannot find hash in the log output

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

Eugene Sajine <euguess@gmail.com> writes:

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

On Thu, Dec 2, 2010 at 3:48 PM, Junio C Hamano <gitster@pobox.com> wrote:

yes. I do see it with your command.

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

Thanks, Eugene

On Thu, Dec 2, 2010 at 4:07 PM, Eugene Sajine <euguess@gmail.com> wrote:

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

On Fri, Dec 03, 2010 at 12:41:52PM -0500, Eugene Sajine wrote:

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

On Fri, Dec 3, 2010 at 12:52 PM, Jeff King <peff@peff.net> 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. 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

Eugene Sajine wrote:

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

On Fri, Dec 3, 2010 at 3:29 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

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

Eugene Sajine wrote:

[...]

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

On Fri, Dec 3, 2010 at 3:55 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

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

Eugene

Jonathan Nieder <jrnieder@gmail.com> writes:

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.

Junio C Hamano wrote:

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.

On Fri, Dec 03, 2010 at 03:10:40PM -0500, Eugene Sajine wrote:

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.

No. We suppress "uninteresting" parts of merges by default because they are mostly clutter. If you really want to see them, use "-m".

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

On Fri, Dec 03, 2010 at 04:11:58PM -0500, Jeff King wrote:

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