On Tue, Jan 02, 2024 at 02:56:50PM -0500, Taylor Blau wrote:
> 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
