Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Oct 19, 2007, 21:57 UTC
Message-ID: <alpine.LFD.0.999.0710191446440.26902@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.0.999.0710191157560.26902@woody.linux-foundation.org>

On Fri, 19 Oct 2007, Linus Torvalds wrote:

> 
> Could be done, but I almost think it would be better to just make the 
> sha1_name.c interfaces take some extended data structure which allows 
> looking up multiple SHA1's at the same time.

Btw, I knew I had wanted this in the past, but I had forgotten why. I now remembered.

The thing is, sometimes you want an expression for "all the parents of X". We don't have that, and again, the current internal implementation of sha1_name.c makes it essentially impossible to do within that interface (ie you can do it on *top* of that interface in revision.c, but it cannot be a general SHA1 expression).

So wouldn't it be nice to have a "commit^*" expression to go with "commit^" and "commit^2" etc? One that would name all the parents. It's useful, for example, for saying that you still want to see that commit, but not any of its parents:

	git log commit^*..

could basically work to show that commit (and all subsequent commits), but not the commits leading up to it. Right now, you can't easily say that in the git "sha1 expression algebra".

There are some other cases where you'd like to have things expand to more than one commit. We currently do those with special flags, like --all, but in many ways it would be really nice to be able to do SHA1 operations on them. If we were to make the SHA1 arithmetic able to handle multiple SHA1's (instead of just one), I could see us being able to do things like

	git diff {master,pu}:Makefile

as a way of saying

	git diff master:Makefile pu:Makefile

which already works - simply because we could make the ":name" be able to operate on multiple commit SHA1's and turn them into multiple blob (or tree) SHA1's.

(The above may not sound very useful, but

	git diff {ORIG_HEAD...MERGE_HEAD}:file

would essentially expand to "base version of file", ORIG_HEAD:file and MERGE_HEAD:file, and we could fairly easily teach diff to do a nice three-way diff for things like this! So it does have potential to be a reasonably powerful model)

			Linus