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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
