Ramkumar Ramachandra <artag...@gmail.com> writes:

> I'm more interested in knowing what you think of my first point: is
> :/text fundamentally broken, as it can't be combined with other
> operators like the other rev specs can?  If so, how do you think we
> should fix it?

The question :/string wants to ask is fundamentally ambiguous once
you start wanting to give arbitrary string to it.

Think what this asks:

    git show ":/Fix regression introduced by commit v1.5.1-rc1"~113^2

Is it looking for a commit that fixes v1.5.1-rc1 and then locate the
side branch that waas merged by the 113th-generation parent of that
fix?  Or is it looking for the commit that fixes v1.5.1-rc1~113^2?

When we introduced a postfix $rev^{/string} operator at 32574b68c57f
(get_sha1: support $commit^{/regex} syntax, 2010-12-13) to dig from
a given rev, we designed it so that we can disambiguate between the
two: HEAD^{/Fix v1.5.1~113^2} vs HEAD^{/Fix v1.5.1}~113^2.

But the tradeoff made with 28a4d9404438 (object name: introduce
':/<oneline prefix>' notation, 2007-02-24), which is much older than
the $rev^{/string} syntax, is to help casual interactive use by not
requiring sometimes-hard-to-type line noise characters.

Even back then, I did not want to paint us into a corner we cannot
escape from, and made sure the syntax has an escape hatch built-in.



If you cared deeply enough, you could activate it, to take something

    git show ":/!(s=Fix regression by v1.5.1-rc1~113^2)~20"

to say "The 20th-generation parent of the commit whose subject says
it fixed regression at v1.5.1-rc1~113^2".

That would make this

        ":/!(a=Ramkumar)(s=move diff.wordRegex)~4"

a way to find the fourth-generation parent of 2ead7a674d7f (t5516
(fetch-push): update test description, 2013-04-02) as a natural
extension, I guess.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to