Skip to contentSkip to conversation

doc: sparse-checkout: Fix list markers

PATCH In review oneee via GitGitGadget 6 participants 11 messages Apr 21, 2025 – May 30, 2025 Documentation

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 doc: sparse-checkout: Fix list markers

From: onee-only <[email protected]>

Changed the list markers from a mix of "(1)" and "(b)" to a consistent numeric format "(1)", "(2)" for clarity and consistency.

---
doc: sparse-checkout: Fix list markers

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1948%2Fonee-only%2Ffix-sparse-checkout-doc-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1948/onee-only/fix-sparse-checkout-doc-v1
Pull-Request: https://github.com/git/git/pull/1948

 Documentation/technical/sparse-checkout.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/technical/sparse-checkout.adoc +1 -1
index dc2e763bbec..8202172b70b 100644
@@ -66,7 +66,7 @@ sparsity patterns: patterns from $GIT_DIR/info/sparse-checkout used to
 	reasons: (1) users in cone mode specify directories rather than
 	patterns (their directories are transformed into patterns, but
 	users may think you are talking about non-cone mode if you use the
-	word "patterns"), and (b) the sparse specification might
+	word "patterns"), and (2) the sparse specification might
 	transiently differ in the working tree or index from the sparsity
 	patterns (see "Sparse specification vs. sparsity patterns").
 

base-commit: 4bbb303af69990ccd05fe3a2eb58a1ce036f8220

Signature · 1 line
gitgitgadget
#1 lore raw
Quoted 1 line

doc: sparse-checkout: Fix list markers

s/Fix/fix/. The initial word after the area should be lower-case. See Documentation/SubmittingPatches (SP), “describe-changes”.

Quoted 4 lines · oneee via GitGitGadget

From: onee-only <[email protected]>

Changed the list markers from a mix of "(1)" and "(b)" to a consistent numeric format "(1)", "(2)" for clarity and consistency.

Commits are described in imperative mood (SB, “imperative-mood”).

Reading the message I thought it was about a larger change to consistently use one style over the other. But you are fixing one application of inline lists to use either numeric or alphabetic(?), specifically falling on numeric.

I would write it as:

doc: sparse-checkout: use consistent inline list style

Fix this inline list to use a single style, namely numeric, instead of (1) followed by (b).

(Numeric or numeral, I’m not sure)

Quoted 1 line

I’m not saying the following is not the case. But FYI the project demands that commit identification needs to be your real name.

Just saying in case it is a pseudonym.

Documentation/technical/sparse-checkout.adoc sparsity patterns: patterns from $GIT_DIR/info/sparse-checkout used to · line 69

Quoted 1 line
Documentation/technical/sparse-checkout.adoc +1 -0
+	word "patterns"), and (2) the sparse specification might

I would also use a semicolon to separate 1 and 2. I think this is the correct style for any list introduced by a colon:

    see here: (1) ...; (2) ...; and (5) ...

Because then you can use commas freely inside each point.

#8 lore raw
In reply to oneee via GitGitGadget
Quoted 4 lines · oneee via GitGitGadget

From: onee-only <[email protected]>

Changed the list markers from a mix of "(1)" and "(b)" to a consistent numeric format "(1)", "(2)" for clarity and consistency.

In Git we use imperative style for commit messages, as if requesting the code to change. So something like this for example:

We use a mix of "(1)" and "(b)" to refer to different cases when explaining sparsity patterns. Adapt these markers to use the numeric format for both clarity and consistency.

Quoted 1 line

We typically prefer your full name instead of using nicknames here. So if you want to provide your full name, please do so.

Documentation/technical/sparse-checkout.adoc sparsity patterns: patterns from $GIT_DIR/info/sparse-checkout used to · line 71

Quoted 12 lines
Documentation/technical/sparse-checkout.adoc +1 -1
index dc2e763bbec..8202172b70b 100644
@@ -66,7 +66,7 @@ sparsity patterns: patterns from $GIT_DIR/info/sparse-checkout used to
 	reasons: (1) users in cone mode specify directories rather than
 	patterns (their directories are transformed into patterns, but
 	users may think you are talking about non-cone mode if you use the
-	word "patterns"), and (b) the sparse specification might
+	word "patterns"), and (2) the sparse specification might
 	transiently differ in the working tree or index from the sparsity
 	patterns (see "Sparse specification vs. sparsity patterns").

The change itself looks like an obvious improvement to me, thanks!

Patrick

#2 lore raw
In reply to Kristoffer Haugsbakk
Quoted 8 lines · Kristoffer Haugsbakk
Quoted 2 lines · oneee via GitGitGadget

Changed the list markers from a mix of "(1)" and "(b)" to a consistent numeric format "(1)", "(2)" for clarity and consistency.

Reading the message I thought it was about a larger change to consistently use one style over the other. But you are fixing one application of inline lists to use either numeric or alphabetic(?), specifically falling on numeric.

I seem to recall that I had a similar reaction when I originally read the commit message.

Quoted 6 lines

I would write it as:

doc: sparse-checkout: use consistent inline list style

Fix this inline list to use a single style, namely numeric, instead of (1) followed by (b).

This does make it clearer.

Quoted 8 lines
Quoted 1 line

+ word "patterns"), and (2) the sparse specification might

I would also use a semicolon to separate 1 and 2. I think this is the correct style for any list introduced by a colon:

    see here: (1) ...; (2) ...; and (5) ...

Because then you can use commas freely inside each point.

I'd like to push back on this suggestion, at least in the context of this particular patch, the purpose of which is to fix an actual problem in the documentation. The sort of improvement you suggest probably ought to be done as a separate patch, but let's not make it seem as if we are heaping extra work on the patch submitter; it's more important to get the fix itself landed.

As such, the patch itself looks obviously correct and is a definite improvement as-is. It's not clear why it didn't get picked up; perhaps it just fell through the cracks.

#3 lore raw
Quoted 9 lines · Eric Sunshine
Quoted 1 line

Because then you can use commas freely inside each point.

I'd like to push back on this suggestion, at least in the context of this particular patch, the purpose of which is to fix an actual problem in the documentation. The sort of improvement you suggest probably ought to be done as a separate patch, but let's not make it seem as if we are heaping extra work on the patch submitter; it's more important to get the fix itself landed.

Quoted 3 lines

As such, the patch itself looks obviously correct and is a definite improvement as-is. It's not clear why it didn't get picked up; perhaps it just fell through the cracks.

Okay, totally reasonable and makes sense IMO.

#4 lore raw

(I'm resending this email since the previous message was blocked due to accidently containing HTML. Thanks for your understanding!)

I'm sorry for the delay.

Quoted 9 lines · Kristoffer Haugsbakk

I would write it as:

doc: sparse-checkout: use consistent inline list style

Fix this inline list to use a single style, namely numeric, instead of (1) followed by (b).

(Numeric or numeral, I’m not sure)

Thanks for the suggestion. I'll update the message as you wrote.

Quoted 7 lines
Quoted 2 lines

I’m not saying the following is not the case. But FYI the project demands that commit identification needs to be your real name.

Just saying in case it is a pseudonym.

I wasn't aware of it. I'll change it into my real name. Thanks for pointing it out.

Quoted 8 lines · Eric Sunshine
Quoted 8 lines
Quoted 2 lines

+ word "patterns"), and (2) the sparse specification might

I would also use a semicolon to separate 1 and 2. I think this is the correct style for any list introduced by a colon:

    see here: (1) ...; (2) ...; and (5) ...
Quoted 8 lines
Quoted 1 line

Because then you can use commas freely inside each point.

I'd like to push back on this suggestion, at least in the context of this particular patch, the purpose of which is to fix an actual problem in the documentation. The sort of improvement you suggest probably ought to be done as a separate patch, but let's not make it seem as if we are heaping extra work on the patch submitter; it's more important to get the fix itself landed.

I'd like to apply it to the same PR in GitHub, producing an additional commit. (I don't fully understand how the system works, sorry).

Thank you all for the reviews!

#5 lore raw
Quoted 17 lines · oneee
Quoted 7 lines · Eric Sunshine
Quoted 7 lines
Quoted 1 line

+ word "patterns"), and (2) the sparse specification might

I would also use a semicolon to separate 1 and 2. I think this is the correct style for any list introduced by a colon:

    see here: (1) ...; (2) ...; and (5) ...
Quoted 8 lines
Quoted 1 line

Because then you can use commas freely inside each point.

I'd like to push back on this suggestion, at least in the context of this particular patch, the purpose of which is to fix an actual problem in the documentation. The sort of improvement you suggest probably ought to be done as a separate patch, but let's not make it seem as if we are heaping extra work on the patch submitter; it's more important to get the fix itself landed.

Quoted 2 lines

I'd like to apply it to the same PR in GitHub, producing an additional commit. (I don't fully understand how the system works, sorry).

You're welcome to submit an additional patch implementing Kristoffer's suggestion. Normally, it would make sense to send them both as a two-patch series, however, I'm not so sure that that would be a good idea in this case. The reason I question it is that the original patch is an obvious and uncontroversial fix, however, Kristoffer's suggestion -- because it is a subjective change -- may get pushback from reviewers. If it does get pushback, then that pushback could hold up the entire series as discussion ensues, thus slowing or even completely derailing the original "fix" patch from being accepted.

#6 lore raw
Quoted 9 lines · Eric Sunshine

You're welcome to submit an additional patch implementing Kristoffer's suggestion. Normally, it would make sense to send them both as a two-patch series, however, I'm not so sure that that would be a good idea in this case. The reason I question it is that the original patch is an obvious and uncontroversial fix, however, Kristoffer's suggestion -- because it is a subjective change -- may get pushback from reviewers. If it does get pushback, then that pushback could hold up the entire series as discussion ensues, thus slowing or even completely derailing the original "fix" patch from being accepted.

That makes sense. I'll submit an additional patch after this one is accepted.

Much appreciated!

#9 lore raw

PATCH v2 1/1 doc: sparse-checkout: use consistent inline list style

In reply to oneee via GitGitGadget

From: Wonuk Kim <[email protected]>

Fix this inline list to use a single style, namely numeric, instead of (1) followed by (b).

---
doc: sparse-checkout: Fix list markers

cc: "Kristoffer Haugsbakk" [email protected] cc: Patrick Steinhardt [email protected] cc: Eric Sunshine [email protected]

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1948%2Fonee-only%2Ffix-sparse-checkout-doc-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1948/onee-only/fix-sparse-checkout-doc-v2
Pull-Request: https://github.com/git/git/pull/1948

Range-diff vs v1:

1: c702bbc8782 ! 1: 6154158b98c doc: sparse-checkout: Fix list markers
@@
## Metadata ##
-Author: onee-only <[email protected]>
+Author: Wonuk Kim <[email protected]>

## Commit message ##
- doc: sparse-checkout: Fix list markers
+ doc: sparse-checkout: use consistent inline list style

- Changed the list markers from a mix of "(1)" and "(b)" to a
- consistent numeric format "(1)", "(2)" for clarity and consistency.
+ Fix this inline list to use a single style, namely numeric, instead of
+ (1) followed by (b).

- Signed-off-by: onee-only <[email protected]>
+ Signed-off-by: Wonuk Kim <[email protected]>

## Documentation/technical/sparse-checkout.adoc ##
@@ Documentation/technical/sparse-checkout.adoc: sparsity patterns: patterns from $GIT_DIR/info/sparse-checkout used to

 Documentation/technical/sparse-checkout.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/technical/sparse-checkout.adoc +1 -1
index dc2e763bbec..8202172b70b 100644
@@ -66,7 +66,7 @@ sparsity patterns: patterns from $GIT_DIR/info/sparse-checkout used to
 	reasons: (1) users in cone mode specify directories rather than
 	patterns (their directories are transformed into patterns, but
 	users may think you are talking about non-cone mode if you use the
-	word "patterns"), and (b) the sparse specification might
+	word "patterns"), and (2) the sparse specification might
 	transiently differ in the working tree or index from the sparsity
 	patterns (see "Sparse specification vs. sparsity patterns").
 

base-commit: 4bbb303af69990ccd05fe3a2eb58a1ce036f8220

Signature · 1 line
gitgitgadget
#7 lore raw
In reply to Eric Sunshine
Quoted 7 lines · Eric Sunshine

You're welcome to submit an additional patch implementing Kristoffer's suggestion. Normally, it would make sense to send them both as a two-patch series, however, I'm not so sure that that would be a good idea in this case. The reason I question it is that the original patch is an obvious and uncontroversial fix, however, Kristoffer's suggestion -- because it is a subjective change -- may get pushback from reviewers.

I had the same thought. If I were working on this topic, I'd send the original as-is with the suggested name fix, let it graduate, and then after all the dust settled, do enumeration-style changes as a new and totally independent patch, which may cover enumerations other than this single instance.

Thanks.