On Mon, Jul 21, 2014 at 04:14:38PM -0700, Jonathan Nieder wrote: > brian m. carlson wrote: > > > The caret (^) is used as a markup symbol in AsciiDoc. Due to the > > inability of AsciiDoc to parse a line containing an unmatched caret, it > > omitted the line from the output, resulting in the man page missing the > > end of a sentence. > > Wow. Usually asciidoc is more forgiving than that. Are there other > pages affected by this too (e.g., "the commit HEAD^" in > user-manual.txt)?
I didn't look at any other pages before submitting this. I noticed when
I was looking up git rev-parse --verify on my Debian sid laptop at work.
I just looked, and the place you mentioned in user-manual.txt wasn't
affected. It looks like this is the only place in running text that we
don't use backticks around the caret-containing text.
> > --- a/Documentation/git-rev-parse.txt
> > +++ b/Documentation/git-rev-parse.txt
> > @@ -102,7 +102,7 @@ eval "set -- $(git rev-parse --sq --prefix "$prefix"
> > "$@")"
> > +
> > If you want to make sure that the output actually names an object in
> > your object database and/or can be used as a specific type of object
> > -you require, you can add "^{type}" peeling operator to the parameter.
> > +you require, you can add "\^{type}" peeling operator to the parameter.
>
> Does using {caret} for ^ work, too? Generally in asciidoc using a
> backslash to escape delimiter characters leads to trouble when the
> number of delimiters changes or the text is copy+pasted, since in a
> context where the backslash is unneeded it ends up being rendered as a
> literal backslash.
{caret} does not work; it leaves the sentence broken still. `^{type}`
does work. Since that seems a bit cleaner, and I think the resultant
formatting is fine, I'll reroll with that change.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
