Thread (38 messages) flat view 38 messages, 7 authors, 2016-06-15

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:43


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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help