[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: git copies of cvs modules available
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
> 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) ]
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.
Main Index |
Thread Index |