Re: [RFC] Using gitrevisions :/search style with other operators

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 9, 2010, 15:59 UTC
Message-ID: <7v4obqo5dk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101109051631.GA19867@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

>> Any comments on my suggestion to specify the ref to search from, e.g.
>> origin/pu:/"Merge 'kb/blame-author-email'"? As I stated before, I believe
>
> It seems to me the natural way to do that would be to use our existing
> generic "start at this ref and follow some chain" syntax, which is
> ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}.
>
> We already use it for "follow tree link" and "peel tag objects", and it
> is syntactically similar to the usual "follow the ancestry chain" syntax
> ("ref^"). And I believe it should be unambiguous, as nothing that could
> go in ^{} could start with ":". And presumably one would have to
> backslash-escape embedded closing curly braces.

Yeah, that may make more sense but I think the operation specifier should be '/', not ':', no?

We chose ':' as a "funky SHA-1 expression introducer" that can be followed by other letters to specify what kind of funkiness is being summoned (in the case of ':/string', you are asking for "search" funkiness), so that we can extend it with different kind of funkiness later. That is where my earlier ':(...)' came from.

Show 5 quoted lines

> We also have ref@{upstream}. The analogue here would be
> origin/pu@{:Merge 'kb/blame-author-email'}.
>
> I don't recall whether we put any conscious thought into ref@{upstream}
> versus ref^{upstream}.

I think that is because it is nonsensical to say sha1@{u} for an arbitrary SHA-1 expression (i.e. the operator only makes sense for a branch ref we can find branch.*.merge for). So from that perspective, you are right that "Start from this commit and find an ancestor whose log message contains this string" goes well with "sha1^{/some string}"