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

Jeff King [off-list ref] writes:

quoted

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.

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}"