Re: Referring to revisions in the git future

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >> There's no reason why the commit message would need to be
 > >> considered as being part of the "immutable history".  IOW
 > >> there's no technical reason to include the commit message in the
 > >> Git hash.

There's no technical reason why anything needs to be considered part
of the immutable history, it's all convention.  And of course (up to
the finite set of SHA1s) both the typo and the fixed message are
already part of immutable history.  The integers aren't going to
change. ;-)

But more practically, Darcs, for example, does not have a DAG at all:
you can easily mix and match patches the would be on different
branches in a DAG-based VCS.  Effectively for our purposes there is no
history, and Darcs users don't seem to miss it.

As a possible way to address this issue, you can always attach "notes"
to a git commit.  vc.el could deal with them reliably even if git's
own UIs refuse to.

 > > git has a separate hash for the tree. "git cat-file commit
 > > <somecommitsha1>" will show you that.
 > 
 > I know, but the "parents" reference a "commit", not a "tree".

Double indirection is not a real problem.  It's just that (as you
validly point out) the tools haven't been written.

BTW, you need to deal with merges (something that you can't do
efficiently in Darcs, which doesn't know about parents anyway).