[PATCH] git-filter-branch.txt: use {caret} for ^

[PATCH] git-filter-branch.txt: use {caret} for ^

[Martin Ågren]

In this paragraph, we have a few instances of the '^' character, which
we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor
renders it literally as "\^". Dropping the backslashes renders fine
with Asciidoctor, but not AsciiDoc... Let's use "{caret}" instead, to
avoid these escaping problems.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 Documentation/git-filter-branch.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index a530fef7e5..9e58d34c6a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -467,9 +467,9 @@ impossible for a backward-compatible implementation to ever be fast:
 
 * In editing files, git-filter-branch by design checks out each and
   every commit as it existed in the original repo.  If your repo has
-  10\^5 files and 10\^5 commits, but each commit only modifies 5
-  files, then git-filter-branch will make you do 10\^10 modifications,
-  despite only having (at most) 5*10^5 unique blobs.
+  10{caret}5 files and 10{caret}5 commits, but each commit only modifies 5
+  files, then git-filter-branch will make you do 10{caret}10 modifications,
+  despite only having (at most) 5*10{caret}5 unique blobs.
 
 * If you try and cheat and try to make git-filter-branch only work on
   files modified in a commit, then two things happen
-- 
2.25.0

Re: [PATCH] git-filter-branch.txt: use {caret} for ^

[Jeff King]

On Sun, Feb 02, 2020 at 08:33:19PM +0100, Martin Ågren wrote:

> In this paragraph, we have a few instances of the '^' character, which
> we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor
> renders it literally as "\^". Dropping the backslashes renders fine
> with Asciidoctor, but not AsciiDoc... Let's use "{caret}" instead, to
> avoid these escaping problems.

Makes sense.

The source is pretty ugly to read both before and after, though. I
wonder if using a literal like `5*10^5` would be even nicer. That makes
the source pretty readable, and the output would put it in <tt> or
similar. Which maybe is a little funny, but kind of makes sense to me
typographically as a kind of "this is math" style.

-Peff

Re: git-filter-branch.txt: wrap "maths" notation in backticks

[Martin Ågren]

On Mon, 3 Feb 2020 at 12:45, Jeff King <peff@peff.net> wrote:
>
> On Sun, Feb 02, 2020 at 08:33:19PM +0100, Martin Ågren wrote:
>
> > In this paragraph, we have a few instances of the '^' character, which
> > we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor
> > renders it literally as "\^". Dropping the backslashes renders fine
> > with Asciidoctor, but not AsciiDoc... Let's use "{caret}" instead, to
> > avoid these escaping problems.
>
> Makes sense.
>
> The source is pretty ugly to read both before and after, though. I

Yeah, I was happy to have improved the situation a bit, but didn't quite
feel that it looked great..

> wonder if using a literal like `5*10^5` would be even nicer. That makes
> the source pretty readable, and the output would put it in <tt> or
> similar. Which maybe is a little funny, but kind of makes sense to me
> typographically as a kind of "this is math" style.

Hmm, that somehow makes sense. How about the below? Outside of RelNotes/
and technical/, I only saw one spot where we could do something similar
("O(n^2)" in diff-options.txt; it has an accompanying loose "n"). I had
actually expected more. Most hits for "{caret}" are in revisions.txt
(duh) and the one hit for "\^" that remains after this patch is a shell
snippet.

Going for "1e5" and so on would be one way, I guess, but suffers from
the same problem that it somehow looks like a random pile of characters
in the middle of a sentence (unless it's typeset in, e.g., monospace).

One could of course move in a different direction entirely and talk
about "a thousand", "a million" and so on...

--->8---
Subject: [PATCH v2] git-filter-branch.txt: wrap "maths" notation in backticks

In this paragraph, we have a few instances of the '^' character, which
we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor
renders it literally as "\^". Dropping the backslashes renders fine
with Asciidoctor, but not AsciiDoc...

An earlier version of this patch used "{caret}" instead of "^", which
avoided these escaping problems. The rendering was still so-so, though
-- these expressions end up set as normal text, similarly to when one
provides, e.g., computer code in the middle of running text, without
properly marking it with `backticks` to be monospaced.

As noted by Jeff King, this suggests actually wrapping these
expressions in backticks, setting them in monospace.

The lone "5" could be left as is or wrapped as `5`. Spell it out as
"five" instead -- this generally looks better anyway for small numbers
in the middle of text like this.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 Documentation/git-filter-branch.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index a530fef7e5..40ba4aa3e6 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -467,9 +467,9 @@ impossible for a backward-compatible implementation to ever be fast:
 
 * In editing files, git-filter-branch by design checks out each and
   every commit as it existed in the original repo.  If your repo has
-  10\^5 files and 10\^5 commits, but each commit only modifies 5
-  files, then git-filter-branch will make you do 10\^10 modifications,
-  despite only having (at most) 5*10^5 unique blobs.
+  `10^5` files and `10^5` commits, but each commit only modifies five
+  files, then git-filter-branch will make you do `10^10` modifications,
+  despite only having (at most) `5*10^5` unique blobs.
 
 * If you try and cheat and try to make git-filter-branch only work on
   files modified in a commit, then two things happen
-- 
2.25.0

Re: git-filter-branch.txt: wrap "maths" notation in backticks

[Elijah Newren]

On Mon, Feb 3, 2020 at 12:37 PM Martin Ågren <martin.agren@gmail.com> wrote:
>
> On Mon, 3 Feb 2020 at 12:45, Jeff King <peff@peff.net> wrote:
> >
> > On Sun, Feb 02, 2020 at 08:33:19PM +0100, Martin Ågren wrote:
> >
> > > In this paragraph, we have a few instances of the '^' character, which
> > > we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor
> > > renders it literally as "\^". Dropping the backslashes renders fine
> > > with Asciidoctor, but not AsciiDoc... Let's use "{caret}" instead, to
> > > avoid these escaping problems.
> >
> > Makes sense.
> >
> > The source is pretty ugly to read both before and after, though. I
>
> Yeah, I was happy to have improved the situation a bit, but didn't quite
> feel that it looked great..
>
> > wonder if using a literal like `5*10^5` would be even nicer. That makes
> > the source pretty readable, and the output would put it in <tt> or
> > similar. Which maybe is a little funny, but kind of makes sense to me
> > typographically as a kind of "this is math" style.
>
> Hmm, that somehow makes sense. How about the below? Outside of RelNotes/
> and technical/, I only saw one spot where we could do something similar
> ("O(n^2)" in diff-options.txt; it has an accompanying loose "n"). I had
> actually expected more. Most hits for "{caret}" are in revisions.txt
> (duh) and the one hit for "\^" that remains after this patch is a shell
> snippet.
>
> Going for "1e5" and so on would be one way, I guess, but suffers from
> the same problem that it somehow looks like a random pile of characters
> in the middle of a sentence (unless it's typeset in, e.g., monospace).
>
> One could of course move in a different direction entirely and talk
> about "a thousand", "a million" and so on...
>
> --->8---
> Subject: [PATCH v2] git-filter-branch.txt: wrap "maths" notation in backticks
>
> In this paragraph, we have a few instances of the '^' character, which
> we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor
> renders it literally as "\^". Dropping the backslashes renders fine
> with Asciidoctor, but not AsciiDoc...
>
> An earlier version of this patch used "{caret}" instead of "^", which
> avoided these escaping problems. The rendering was still so-so, though
> -- these expressions end up set as normal text, similarly to when one
> provides, e.g., computer code in the middle of running text, without
> properly marking it with `backticks` to be monospaced.
>
> As noted by Jeff King, this suggests actually wrapping these
> expressions in backticks, setting them in monospace.
>
> The lone "5" could be left as is or wrapped as `5`. Spell it out as
> "five" instead -- this generally looks better anyway for small numbers
> in the middle of text like this.
>
> Suggested-by: Jeff King <peff@peff.net>
> Signed-off-by: Martin Ågren <martin.agren@gmail.com>
> ---
>  Documentation/git-filter-branch.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
> index a530fef7e5..40ba4aa3e6 100644
> --- a/Documentation/git-filter-branch.txt
> +++ b/Documentation/git-filter-branch.txt
> @@ -467,9 +467,9 @@ impossible for a backward-compatible implementation to ever be fast:
>
>  * In editing files, git-filter-branch by design checks out each and
>    every commit as it existed in the original repo.  If your repo has
> -  10\^5 files and 10\^5 commits, but each commit only modifies 5
> -  files, then git-filter-branch will make you do 10\^10 modifications,
> -  despite only having (at most) 5*10^5 unique blobs.
> +  `10^5` files and `10^5` commits, but each commit only modifies five
> +  files, then git-filter-branch will make you do `10^10` modifications,
> +  despite only having (at most) `5*10^5` unique blobs.

Looks good to me.

>  * If you try and cheat and try to make git-filter-branch only work on
>    files modified in a commit, then two things happen

It's so tempting to remove "try and" to get rid of the duplicate "try"
at the same time...

Re: git-filter-branch.txt: wrap "maths" notation in backticks

[Jeff King]

On Mon, Feb 03, 2020 at 09:36:50PM +0100, Martin Ågren wrote:

> --->8---
> Subject: [PATCH v2] git-filter-branch.txt: wrap "maths" notation in backticks

Yep, this looks fine to me. Thanks.

(I'd consider it fine to also put the O(n^2) you found in backticks, but
if it renders fine in both places already, I'm happy either way).

-Peff