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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Oct 19, 2007, 04:21 UTC
Message-ID: <alpine.LFD.0.999.0710182111030.26902@woody.linux-foundation.org>
In-Reply-To: <20071019035647.GA18717@coredump.intra.peff.net>

On Thu, 18 Oct 2007, Jeff King wrote:

> 
> As for a shortcut notation, what about allowing '..' notation inside a
> reflog. I.e., <ref>@{a..b} is the same as <ref>@{a}..<ref>@{b}? So you
> could perhaps do origin/master@{1..}?

I'd love it, but the way our current SHA1 parser works, I don't think it can really do it.

Basically, we currently assume that a SHA1 expression always expands to a *single* SHA1.

And then, on top of that SHA1 expression parser, we then have a totally separate logic (which is *not* part of the SHA1 expression parser itself) that handles the "a..b" and "a...b" cases.

In other words, all the magic "head@{xyz}" logic is all in sha1_name.c, but that never handles any ranges at all.

And then the range handling is a separate thing in revision.c and builtin-rev-parse.c.

So I think your syntax is wonderful, but it would require moving the complex range handling into sha1_name.c, and would also require that file to get a more complex interface (right now all the sha1_name.c routines just take the "fill in this one SHA1 hash" approach, but ".." and "..." means that you have multiple objects *and* you can mark one of them as being "negated" etc..)

> I'm not sure if there are syntactic issues with parsing out the '..' (or
> '...') operator.

See above: I don't think we have syntax problems per se: it's just that right now the "complex" parser (the one that knows about ^, ~, and @{x} etc) simply cannot do anything but a single SHA1 due to internal interface issues.

		Linus