Re: [doc] User Manual Suggestion

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.04.25 15:36:24 -0400, David Abrahams wrote:
> Where it's relevant when the user notices that two distinct files have  
> the same id (because they happen to have the same contents) and wonders 
> what's up.

Why would the user have to care about the object files in the repo? And
why would your implementation save the same object twice, in two
distinct files? The SHA-1 hash is created from the object, that means
the its type, size and data. It's not an id of a file in the working
tree, but of an object.

> It's not a foregone conclusion that objects with the same value have  
> identical ids, but it's immediately apparent if the id is known to be a 
> hash.

You can't have two objects with the same contents to begin with, same
content => same object.  You can just have that one object stored
multiple times in different places (for sane implementations this likely
means that you have more than one repo to look at, and each has its own
copy of that object, but that's nothing you as an user should have to
care about).

It's an identity relation: same name/id => same object. Unlike e.g. a
hash-table where you are expected to deal with collisions, and having
the same hash doesn't mean that you have identical data. But that's not
true of git, it expects an identity relation, which is IMHO better
expressed through "object name" or "object id". You can still say that
the name/id is generated by using a hash function, but the important
part is that the name/id is used to _uniquely_ identify an object, which
isn't apparent when you call it a hash.

Björn