Re: Announce: Linux-next (Or Andrew's dream :-))

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote:
> One idea that I thought about when debating rebase vs. merge (and it's
> far far from being fully baked) is versioned commits.  The gist of it
> is that patches are assigned an hash identifier like today when they
> are first committed into the tree, but, and this is the main change:
> if they mutate, e.g. by a rebase, or even git commit --amend, their
> version is bumped up rather than SHA changed.

The SHA1 is uniquely determined by the contents of that commit--commit
and author names and times, changelog message, snapshot of the tree at
that point, and parents--hence, recursively, by the entire history
leading up to that commit.

Naming objects by their content in that way has a lot of advantages--for
example, you can sign an entire history by signing just the SHA1 of the
commit at its tip.  So you can't break that link between the names of
commits and their contents without ending up with a fundamentally
different (and probably weaker, in some sense), system.

I suspect there's an unavoidable tradeoff--if you want to be able to
reliably and efficiently determine how two branches are related, then
you can't just throw away their (possibly messy) history.  The best you
may be able to do, if you want the advantages of both rebasing and
merging, is to maintain on your own the messier meta-history as a
superset of the simpler history that you end up submitting.

--b.

> This way all versions of the commit would be accessible and addressable using
> their respective SHA *and* version. I think that this can help keep
> the tree's history in a more intuitive way (since the patches' base identifier
> won't change, just its version number), and you get a bonus of seeing each
> commit's history, who changed it, and what was the change.