Re: git copies of cvs modules available

[Michal Suchanek <hramrach%centrum.cz@localhost>]

2009/10/29 Holger Weiss <lists%jhweiss.de@localhost>:
> * Michal Suchanek <hramrach%centrum.cz@localhost> [2009-10-29 09:54]:
>> 2009/10/29 Arnaud Lacombe <lacombar%gmail.com@localhost>:
>> > On Tue, Oct 27, 2009 at 9:10 PM, Greg A. Woods <woods%planix.ca@localhost> 
>> > wrote:
>> >> ..., humans usually just want to see if the IDs are the same or not,
>> >> perhaps with some hint as to their relationship in time if they're not.
>> >
>> > well, as an heavy git user, what I want to know is if the source I'm
>> > looking at are the same as the one who has an issue with the source.
>> > With a SHA1, no matter on which repo I'll look at, I will have this
>> > guarantee (minus an improbable collision). CVS doesn't provide this
>> > basic guarantee that 2 same filename with the same CVS number check
>> > out at different time are the same (data corruption or malicious
>> > change). That is a serious flaw.
>>
>> The hash git gives you is changeset hash (or something like that).
>> This changes every time you reapply the changeset to a different repo
>> or a different branch of the same repo and has nothing to do with file
>> hashes.
>
> Git stores the contents of files as blob objects which are referenced
> via their SHA1 hash in just the same way as commit objects. For $Id$
> expansion, the SHA1 of the blob object is used:
>
> | When the attribute ident is set for a path, git replaces $Id$ in
> | the blob object with $Id:, followed by the 40-character hexadecimal
> | blob object name, followed by a dollar sign $ upon checkout.
>
> [ gitattributes(5) ]
>

Well, whatever.

It's equally meaningless once the file is checked out because it's not
the hash of the checked out file nor anything else user-visible.

At least it might stay the same if the file migrates to another repo or branch.

Thanks

Michal