Ramkumar Ramachandra <[email protected]> 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.
cf.
http://thread.gmane.org/gmane.comp.version-control.git/40460/focus=40477
If you cared deeply enough, you could activate it, to take something
like:
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
