Jeff King <peff@xxxxxxxx> writes:
>> 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}"
--
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