From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 19 Oct 2007 04:21:55 GMT
Subject: Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
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