Re: [PATCH] git-clone.txt: document -4 and -6

From: Taylor Blau <me@ttaylorr.com>
Date: Jan 2, 2024, 20:36 UTC
Message-ID: <ZZRzxZNb2Aq+2feW@nand.local>
In-Reply-To: <ZZRqgmDycyAXCrGZ@nand.local>

On Tue, Jan 02, 2024 at 02:56:50PM -0500, Taylor Blau wrote:

Show 14 quoted lines

> It turned up the following results:
>
>     -a
>     --depth
>     --shallow-since
>     --shallow-exclude
>     --no-tags
>     --recurse-submodules
>     -j, --jobs
>     -u, --upload-pack
>     -q, --quiet
>     -v, --verbose
>     --progress
>     -o, --server-option

Hmm. I think the story is a little more complicated. Just looking at the ones that we agree on:

  * -j, --jobs
  * -u, --upload-pack
  * --progress
  * -o, --server-option
  * --[ipv]4
  * --[ipv]6

Note that the 'clone' and 'fetch' versions for many of these options have different wording. For example, in Documentation/git-clone.txt we have:

    -j::
    --jobs=<n>::
           Number of parallel children to be used for all forms of fetching.

Whereas the description in the original fetch-options.txt is more verbose.

In fact, the story is even more complicated than that, since even though the 'push' builtin would benefit from having a shared source of documentation for the --ipv4 and --ipv6 options, 'push' does not have a --jobs option.

'clone', 'fetch', and 'pull' all share an '--upload-pack' option as you note, though 'push' naturally doesn't (so we would need another ifdef there, too). But the instances in 'clone', 'fetch', and 'pull' all differ in their wording (e.g., the 'clone' documentation says "the repository to clone from ..." but the others say "the repository to fetch from ...").

--progress could be shared, as could --server-option, and the two --ipv4/6 options. But the number of nested ifdefs necessary to share the other options probably dose not justify the effort to do so.

Thanks, Taylor