ident hash usage question

Hi,

Please correct me if I’m missing something, but:

I was able to get the $Id$ keyword to show the SHA-1 hash of the file
content, which is done using ident in gitattributes. Now I’m trying to
find a way to get more info about the file using only this hash.

Could you , please, advise if there is a way to get file name and path
inside the repo by having only this Blob hash?

Thank you,
Eugene

On Tue, Oct 20, 2009 at 19:24, Eugene Sajine [off-list ref] wrote:

I was able to get the $Id$ keyword to show the SHA-1 hash of the file
content, which is done using ident in gitattributes. Now I’m trying to
find a way to get more info about the file using only this hash.

Could you , please, advise if there is a way to get file name and path
inside the repo by having only this Blob hash?

It is not possible.

But you can save the commits hash in your blob. Then you'll have everything.
That how git knows it's version.

On Tue, Oct 20, 2009 at 20:16, Alex Riesen [off-list ref] wrote:

On Tue, Oct 20, 2009 at 19:24, Eugene Sajine [off-list ref] wrote:

quoted

I was able to get the $Id$ keyword to show the SHA-1 hash of the file
content, which is done using ident in gitattributes. Now I’m trying to
find a way to get more info about the file using only this hash.

Could you , please, advise if there is a way to get file name and path
inside the repo by having only this Blob hash?

It is not possible.

Well, not exactly impossible, but you can end up with multiple paths,
some of which may not have anything to do the original path.

Just run git log --no-abbrev --raw --all and grep for the SHA-1

Well, not exactly impossible, but you can end up with multiple paths,
some of which may not have anything to do the original path.

Just run git log --no-abbrev --raw --all and grep for the SHA-1

This is exactly what I was looking for! Thank you!

I understand that in some cases this can give me two paths instead of
one, but it will only demonstrate that I have absolute copy of a file
inside my repo, which is also good to diagnose (because the
probability of having two meaningful files with the same hash, but
different content is way too low).

So, this means that after few little tricks the keyword expansion
problem may be resolved by only using $Id$ keyword.
Because after having this hash one can build up all necessary info from it:

#finding blobs with SHA indicated in $Id$ keword
$ git log --no-abbrev --raw --all | grep SHA-1

# little script or regexp here (don’t have it)
$ pull out path from result

# last commit for the path with all corresponding info
$ git log -1 HEAD path

So, this seems to cover most of the needs of people who would like to
use keywords expansion, if they are not ready to forget about them…

Does it make sense?

Thanks,
Eugene

On Tue, Oct 20, 2009 at 20:59, Eugene Sajine [off-list ref] wrote:

quoted

Well, not exactly impossible, but you can end up with multiple paths,
some of which may not have anything to do the original path.

Just run git log --no-abbrev --raw --all and grep for the SHA-1

This is exactly what I was looking for! Thank you!

Very likely it isn't, but it's your choice.

Because after having this hash one can build up all necessary info from it:

Depending on your definition of "necessary".

#finding blobs with SHA indicated in $Id$ keword
$ git log --no-abbrev --raw --all | grep SHA-1

yeah. These are all starting from commit which introduced
the hash under a specific path, ending at the commit where
the path contains another SHA-1.

# little script or regexp here (don’t have it)
$ pull out path from result

# last commit for the path with all corresponding info
$ git log -1 HEAD path

So, this seems to cover most of the needs of people who would like to
use keywords expansion, if they are not ready to forget about them…

Does it make sense?

Not much. You'll always get a long list of commits which didn't
change the damned blob. And you have absolutely no way
to find out exactly which of the commits have produced
the blob you're looking at (because you decided to do away
with the information).

What's so hard with storing the SHA-1 of the *commit*, anyway?

On Dienstag, 20. Oktober 2009, Alex Riesen wrote:

What's so hard with storing the SHA-1 of the *commit*, anyway?

The hard part is that you get a cycle: commit SHA1 depends on contents depends 
on commit SHA1.

-- Hannes

First, thank you for your answers!

Very likely it isn't, but it's your choice.

;)

quoted

Because after having this hash one can build up all necessary info from it:

Depending on your definition of "necessary".

I'm trying to find a way to get to state where i can do

$ git log <path>

Or any other variants of it without introducing any non-default
scripts/features/keywords and limiting keywords to one to avoid any
related problem...

One of my friends said that git is not working for their development
model... C++ development with static linking across the board, where
they need to see exactly which version of the file has got to the
executable. Roughly, they are using CVS' keywords and revision numbers
and a script wich matches them between two versions of the
executables.

I've got curious if Git can support it and how it can be done with
minimal changes to workflow.

quoted

#finding blobs with SHA indicated in $Id$ keword
$ git log --no-abbrev --raw --all | grep SHA-1

yeah. These are all starting from commit which introduced
the hash under a specific path, ending at the commit where
the path contains another SHA-1.

Actually, grep "SHA-1 A" will show added path(s) only, so this is resolved

quoted

# little script or regexp here (don’t have it)
$ pull out path from result

# last commit for the path with all corresponding info
$ git log -1 HEAD path

So, this seems to cover most of the needs of people who would like to
use keywords expansion, if they are not ready to forget about them…

Does it make sense?

Not much. You'll always get a long list of commits which didn't
change the damned blob. And you have absolutely no way
to find out exactly which of the commits have produced
the blob you're looking at (because you decided to do away
with the information).

How is that? It seams to me that git log <path> will show only commits
where <path> was changed/committed? Considering the fact that I've got
the initial path from the blob, i should get the exact commit history
(or last commit in my example) for the file(s) (Files if renaming
occurred without content change).

Thanks,
Eugene

On Tue, Oct 20, 2009 at 22:22, Johannes Sixt [off-list ref] wrote:

On Dienstag, 20. Oktober 2009, Alex Riesen wrote:

quoted

What's so hard with storing the SHA-1 of the *commit*, anyway?

The hard part is that you get a cycle: commit SHA1 depends on contents depends
on commit SHA1.

Don't store it in the repo. Store it in the output.

On Tue, Oct 20, 2009 at 22:30, Eugene Sajine [off-list ref] wrote:

One of my friends said that git is not working for their development
model... C++ development with static linking across the board, where
they need to see exactly which version of the file has got to the
executable. Roughly, they are using CVS' keywords and revision numbers
and a script wich matches them between two versions of the
executables.

As soon as your friend understand, that a commit describes the complete
state of the repository on the moment of commit, he/she will notice that
the commit allows to find each what content each file in the product
had at the moment of compilation and linking (assuming they weren't
compiling uncommitted tree, which RCS/CVS/SVN/Perforce mindset
tends to encourage).

I've got curious if Git can support it and how it can be done with
minimal changes to workflow.

Depends on workflow, I afraid. And I personally wouldn't bother.

quoted

quoted

# little script or regexp here (don’t have it)

Does it make sense?

Not much. You'll always get a long list of commits which didn't
change the damned blob. And you have absolutely no way
to find out exactly which of the commits have produced
the blob you're looking at (because you decided to do away
with the information).

How is that? It seams to me that git log <path> will show only commits
where <path> was changed/committed? Considering the fact that I've got
the initial path from the blob, i should get the exact commit history
(or last commit in my example) for the file(s) (Files if renaming
occurred without content change).

The blob is present in each commit since it was introduced. Except
when your project contains only that one blob, isn't the state of
the other parts of an interest?

quoted

How is that? It seams to me that git log <path> will show only commits
where <path> was changed/committed? Considering the fact that I've got
the initial path from the blob, i should get the exact commit history
(or last commit in my example) for the file(s) (Files if renaming
occurred without content change).

The blob is present in each commit since it was introduced. Except
when your project contains only that one blob, isn't the state of
the other parts of an interest?

I would question this statement. It seems to me that hash of the file
content is logged only for the commit when it was touched.
Therefore there is very limited amount of actual commits where the
same hash can be met.

Thanks,
Eugene

On Wed, Oct 21, 2009 at 00:19, Eugene Sajine [off-list ref] wrote:

quoted

quoted

How is that? It seams to me that git log <path> will show only commits
where <path> was changed/committed? Considering the fact that I've got
the initial path from the blob, i should get the exact commit history
(or last commit in my example) for the file(s) (Files if renaming
occurred without content change).

The blob is present in each commit since it was introduced. Except
when your project contains only that one blob, isn't the state of
the other parts of an interest?

I would question this statement. It seems to me that hash of the file
content is logged only for the commit when it was touched.
Therefore there is very limited amount of actual commits where the
same hash can be met.

git rev-list HEAD | while read sha; do git ls-tree $sha; done | grep <blob-sha>

Many thanks to everybody for your time and comments!

I have plenty of info to think about now...;)

With best regards,
Eugene