* 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