Andreas Heiduk <[email protected]> writes:
> Am 16.08.2017 um 05:21 schrieb ryenus:
>> To make sure the `<text>` in `:/<text>` is seen as one search string,
>> one should quote/escape `<text>` properly.
>>
>> Especially, the example given in the manual `:/fix nasty bug` does not
>> work because of missing quotes. The examples are now corrected, and a
>> note about quoting/escaping is added as well.
>
> Right now the documentation describes the syntax as git sees the
> parameters. This is agnostic of the shell or other UI with their
> different quoting rules. For example users of fish must quote
> `rev@{2}`. A GUI might require no quoting at all. In that case `:/"fix
> nasty bugs"` would be given to git verbatim and hence not find the revision.
These are all good points that I didn't consider when responding.
> Also: Other examples like `HEAD@{5 minutes ago}` need the same quoting.
>
> So my suggestion is to not use quoting in the examples and provide only
> a hint in the text. Example:
>
> <rev>{caret}{/<text>}', e.g. 'HEAD^{/fix nasty bug}'::
> A suffix '{caret}' to a revision parameter, followed by a brace
> pair that contains a text led by a slash,
> is the same as the ':/fix nasty bug' syntax below except that
> it returns the youngest matching commit which is reachable from
> the '<rev>' before '{caret}'.
> + Depending on the given text the shell's word splitting rules
> + might require additional quoting.
That sounds like a very safe change to adopt, regardless of what we
decide to do to the other part of the proposed change.
Thanks.
