* doc: git-clone: Improve discoverability of --no-single-branch flag
@ 2025-04-30 16:09 Lino Haupt
2025-04-30 16:49 ` Kristoffer Haugsbakk
0 siblings, 1 reply; 4+ messages in thread
From: Lino Haupt @ 2025-04-30 16:09 UTC (permalink / raw)
To: git
Dear Git developers,
this is a minor usability suggestion
git version: 2.47.2 (NixOS)
and https://git-scm.com/docs/git-clone
Short Explanation:
`git clone --help` shows `--no-single-branch` only inside the
`--depth` paragraph. The canonical option paragraph
`--[no]-single-branch` is hard to find when searching for the
exact forms `--single-branch` or `--no-single-branch`.
Extended Explanation:
This reduces discoverability for users who quickly try to search
or grep those options. I myself was confused by this.
The search term '--[no]-single-branch' is not intuitive.
Of course, searching 'single-branch' finds the option paragraph,
but maybe only a secondary / tertiary choice.
A second issue is that one has to deduce what exactly the 'no'
shall negate. This is not complicated but may leave inexperience
users unsure of the expected behavior.
Suggestion:
Below is a drop-in replacement that (a) places both variants in their
own paragraph and (b) spells out the negated form explicitly,
removing the need to deduce what the “no-” prefix negates.
--single-branch
Clone only the history leading to the tip of a single branch, either
specified by the --branch option or the primary branch remote’s
HEAD points at. Further fetches into the resulting repository will
only update the remote-tracking branch for the branch this option
was used for the initial cloning. If the HEAD at the remote did not
point at any branch when --single-branch clone was made, no
remote-tracking branch is created.
--no-single branch
Opposite of --single-branch: clone histories leading to the the tips of
all branches.
Thanks for all the great work on Git!
Best regards,
Lino Haupt
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: doc: git-clone: Improve discoverability of --no-single-branch flag
2025-04-30 16:09 doc: git-clone: Improve discoverability of --no-single-branch flag Lino Haupt
@ 2025-04-30 16:49 ` Kristoffer Haugsbakk
2025-04-30 19:17 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Kristoffer Haugsbakk @ 2025-04-30 16:49 UTC (permalink / raw)
To: Lino Haupt, git
On Wed, Apr 30, 2025, at 18:09, Lino Haupt wrote:
> Dear Git developers,
>
> this is a minor usability suggestion
>
> git version: 2.47.2 (NixOS)
> and https://git-scm.com/docs/git-clone
>
> Short Explanation:
> `git clone --help` shows `--no-single-branch` only inside the
> `--depth` paragraph. The canonical option paragraph
> `--[no]-single-branch` is hard to find when searching for the
> exact forms `--single-branch` or `--no-single-branch`.
>
> Extended Explanation:
> This reduces discoverability for users who quickly try to search
> or grep those options. I myself was confused by this.
> The search term '--[no]-single-branch' is not intuitive.
> Of course, searching 'single-branch' finds the option paragraph,
> but maybe only a secondary / tertiary choice.
> A second issue is that one has to deduce what exactly the 'no'
> shall negate. This is not complicated but may leave inexperience
> users unsure of the expected behavior.
>
> Suggestion:
> Below is a drop-in replacement that (a) places both variants in their
> own paragraph and (b) spells out the negated form explicitly,
> removing the need to deduce what the “no-” prefix negates.
>
> --single-branch
> Clone only the history leading to the tip of a single branch, either
> specified by the --branch option or the primary branch remote’s
> HEAD points at. Further fetches into the resulting repository will
> only update the remote-tracking branch for the branch this option
> was used for the initial cloning. If the HEAD at the remote did not
> point at any branch when --single-branch clone was made, no
> remote-tracking branch is created.
>
> --no-single branch
> Opposite of --single-branch: clone histories leading to the the tips of
> all branches.
Many options are documented as `--[no-]`.
git grep --fixed-string -- '--[no-]' Documentation/ ':(exclude)Documentation/RelNotes/'
This is explained in gitcli(7), “Enhanced Option Parser” (for some
commands), “Negating options”:
Options with long option names can be negated by prefixing
--no-. For example, git branch has the option --track which is on
by default. You can use --no-track to override that
behaviour. The same goes for --color and --no-color.
A concern might be that changing `--single-branch` in this way would be
inconsistent with the overall style.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: doc: git-clone: Improve discoverability of --no-single-branch flag
2025-04-30 16:49 ` Kristoffer Haugsbakk
@ 2025-04-30 19:17 ` Junio C Hamano
2025-05-01 18:10 ` D. Ben Knoble
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2025-04-30 19:17 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: Lino Haupt, git
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail•com> writes:
> Many options are documented as `--[no-]`.
>
> git grep --fixed-string -- '--[no-]' Documentation/ ':(exclude)Documentation/RelNotes/'
>
> This is explained in gitcli(7), “Enhanced Option Parser” (for some
> commands), “Negating options”:
>
> Options with long option names can be negated by prefixing
> --no-. For example, git branch has the option --track which is on
> by default. You can use --no-track to override that
> behaviour. The same goes for --color and --no-color.
>
> A concern might be that changing `--single-branch` in this way would be
> inconsistent with the overall style.
A pair of quick counts:
$ git grep -E -e '^`?--no-' Documentation/ | wc -l
189
$ git grep -E -e '^`?--\[no-\]' Documentation/ | wc -l
80
I think we should try to unify to the following style:
`--frotz=<string>`::
`--no-frotz`::
When `--frotz` is given, the command does THIS using the
given argument <string> IN THIS WAY. The default is not to
to THIS, unless SUCH AND SUCH CONDITION, in which case THAT
is used implicitly as <string>. To disable THIS even when
SUCH AND SUCH CONDITION is met, use `--no-frotz`.
That is:
* Both positive and negative form are given separately as a
headline item, so that "grep" would work well;
* The description should be unified, so that it is clear to readers
what happens when the positive form is given, when the negative
form is given, and when neither is given.
* Mark-up the text that the users MUST input literally inside a
pair of backquotes.
Which means that existing "--[no-]opt::" heading should become two
lines, "`--opt`::" and "`--no-opt`::".
Thanks.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: doc: git-clone: Improve discoverability of --no-single-branch flag
2025-04-30 19:17 ` Junio C Hamano
@ 2025-05-01 18:10 ` D. Ben Knoble
0 siblings, 0 replies; 4+ messages in thread
From: D. Ben Knoble @ 2025-05-01 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristoffer Haugsbakk, Lino Haupt, git
On Wed, Apr 30, 2025 at 3:19 PM Junio C Hamano <gitster@pobox•com> wrote:
>
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail•com> writes:
>
> > Many options are documented as `--[no-]`.
> >
> > git grep --fixed-string -- '--[no-]' Documentation/ ':(exclude)Documentation/RelNotes/'
> >
> > This is explained in gitcli(7), “Enhanced Option Parser” (for some
> > commands), “Negating options”:
> >
> > Options with long option names can be negated by prefixing
> > --no-. For example, git branch has the option --track which is on
> > by default. You can use --no-track to override that
> > behaviour. The same goes for --color and --no-color.
> >
> > A concern might be that changing `--single-branch` in this way would be
> > inconsistent with the overall style.
>
> A pair of quick counts:
>
> $ git grep -E -e '^`?--no-' Documentation/ | wc -l
> 189
> $ git grep -E -e '^`?--\[no-\]' Documentation/ | wc -l
> 80
>
> I think we should try to unify to the following style:
>
> `--frotz=<string>`::
> `--no-frotz`::
> When `--frotz` is given, the command does THIS using the
> given argument <string> IN THIS WAY. The default is not to
> to THIS, unless SUCH AND SUCH CONDITION, in which case THAT
> is used implicitly as <string>. To disable THIS even when
> SUCH AND SUCH CONDITION is met, use `--no-frotz`.
>
> That is:
>
> * Both positive and negative form are given separately as a
> headline item, so that "grep" would work well;
>
> * The description should be unified, so that it is clear to readers
> what happens when the positive form is given, when the negative
> form is given, and when neither is given.
>
> * Mark-up the text that the users MUST input literally inside a
> pair of backquotes.
>
> Which means that existing "--[no-]opt::" heading should become two
> lines, "`--opt`::" and "`--no-opt`::".
>
> Thanks.
>
See also https://lore.kernel.org/git/xmqqjzanzy8k.fsf@gitster.g/,
where I had some similar questions (and got similar answers). We also
merged 4ad47d2de3 (gitcli: document that command line trumps config
and env, 2025-01-16) as a result.
If I'm reading right, this suggestion differs from the previous
conversation that it's worth splitting --[no-]opt into --opt/--no-opt,
which might be valuable for searches of the kind Lino described.
I did eventually push beeabf89 (vim: try harder to find long options,
2025-01-19) [1] to my Dotfiles to work around the current
documentation patterns. I press either `-x` or `_XXX` when searching
for an option (short x, long XXX) in a manual page with those Vim
keybindings, but hopefully the patterns are useful to other people.
For long options, that's
/^\C\v\s*(-[^,]*,\s*)?--(\[no-\])?
[1]: https://github.com/benknoble/Dotfiles/commit/beeabf89
--
D. Ben Knoble
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-05-01 18:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-30 16:09 doc: git-clone: Improve discoverability of --no-single-branch flag Lino Haupt
2025-04-30 16:49 ` Kristoffer Haugsbakk
2025-04-30 19:17 ` Junio C Hamano
2025-05-01 18:10 ` D. Ben Knoble
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox