Re: VCS comparison table

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 26 Oct 2006, Vincent Ladeuil wrote:

> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
> 
>     Linus> Commits are defined by a _combination_ of:
> 
>     Linus>  - the tree they commit (which is recursive, so the
>     Linus>  commit name indirectly includes information EVERY
>     Linus>  SINGLE BIT in the whole tree, in every single file)
> 
> And here you keep that separate from any SCM related info,
> right ?

I don't understand that question.

The commits contain the tree information. A raw commit in git (this is the 
true contents of the current top commit in my kernel tree, just added 
indentation and an empty line between the command I used to generate it 
and the output, to make it stand out better in the email) looks something 
like this:

   [torvalds@g5 linux]$ git-cat-file commit HEAD

   tree ba1ed8c744654ca91ee2b71b7cdee149c8edbef1
   parent 2a4f739dfc59edd52eaa37d63af1bd830ea42318
   parent 012d64ff68f304df1c35ce5902f5023dc14b643f
   author Linus Torvalds <torvalds@g5.osdl.org> 1161873881 -0700
   committer Linus Torvalds <torvalds@g5.osdl.org> 1161873881 -0700
   
   Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
   
   * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
     [SPARC64]: Fix memory corruption in pci_4u_free_consistent().
     [SPARC64]: Fix central/FHC bus handling on Ex000 systems.

where the _name_ of the commit is 

   [torvalds@g5 linux]$ git-rev-parse HEAD

   e80391500078b524083ba51c3df01bbaaecc94bb

ie the commit itself contains the exact tree name (and the name of the 
parents), and the name of the commit is literally the SHA1 of the contents 
of the commit (plus a git-specific header).

>     >> Trees are defined by their content only ?
> 
>     Linus> Where "contents" does include names and
>     Linus> permissions/types (eg execute bit and symlink etc).
> 
> Which can also be expressed as: "Everything the user can
> manipulate outside the SCM context", right ?

Again, I'm not sure what you mean by that. The SCM does not track 
_everything_. It does not track user names and inode numbers, so in a 
sense a developer can change things that the SCM simply doesn't _care_ 
about and never tracks. But yes, the tree contents uniquely identify the 
exact contents that the user cares about.

>     Linus> If you compare the commit name, and they are equal,
>     Linus> you automatically know
> 
>     Linus>  - the trees are 100% identical
>     Linus>  - the histories are 100% identical
> 
> And that's the only info you can get, no ordering here.

No, there is ordering there too. But yes, the ordering is not in the name 
itself, you have to go look at the actual commit history to see it.

The name is just an identifier.

>     Linus> If you only care about the actual tree, you compare
>     Linus> the tree name for equality, ie you can do
> 
>     Linus> 	git-rev-parse commit1^{tree} commit2^{tree}
> 
>     Linus> and compare the two: if and only if they are equal are
>     Linus> the actual contents 100% equal.
> 
> Actually, that's backwards:
> 
> "their actual contents are equal" implies "their signatures are
> equal".

No. 

If the signatures are equal, the contents are equal, and vice versa. It 
really is a two-way thing.

> But, two totally different trees can have the same signature.

No. Don't even think that way. That just confuses you. The hash is 
cryptographic, and large enough, that you really can equate the contents 
with the hash. Anything else is just not even interesting.