Re: [PATCH v2 08/12] submodule--helper: report "submodule" as our name in "-h" output

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> Change the rest of the usage output for "git submodule--helper" so
> that it will pretend to be named "git submodule", which it already did
> e.g. in the case of "status", "deinit" and "update".
>
> This will allow us to eventually dispatch further into "git
> submodule--helper" from git-submodule.sh, while emitting the correct
> usage output.
>
> This does make the usage output of "git submodule--helper" itself
> "incorrect", but since nothing user-facing invokes it directly it
> makes sense to continue to elide that difference entirely. A user
> isn't served by us exposing this internal implementation detail.

Everything up to here makes sense. I agree that "git submodule--helper"
should have been pretending to be "git submodule" wherever possible.

Before now, it probably didn't matter much because it's quite hard to
get "git submodule--helper" to print usage without being first
intercepted by "git submodule", but we'll need it now. Which brings us
to..

> This fixes a bug that's been there ever since "git submodule
> absorbgitdirs" was added in f6f85861400 (submodule: add absorb-git-dir
> function, 2016-12-12). Before this we'd emit e.g. this on invalid
> usage:
>
> 	$ git submodule absorbgitdirs --blah
> 	error: unknown option `blah'
> 	usage: git submodule--helper absorbgitdirs [<options>] [<path>...]

We actually used to output the internal-only name of the
submodule--helper subcommand, i.e.

  git submodule--helper absorb-git-dirs

with the dashes.

> Now we'll emit the same, except that the usage line is now referring
> to the correct command run by the user:
>
> 	usage: git submodule absorbgitdirs [<options>] [<path>...]
> 	[.. same usage output ...]

I initially wondered why "absorbgitdirs" deserved a special shoutout
when we are changing several other subcommands in the same patch, but
it turns out that this usage string bug probably is
"absorbgitdirs"-specific.

"absorbgitdirs" is the only subcommand that doesn't have an options
parsing loop that catches invalid options, it's just:

  cmd_absorbgitdirs()
  {
    git submodule--helper absorb-git-dirs --prefix "$wt_prefix" "$@"
  }

whereas in other subcommands, invalid usage would be caught by by the
options parsing loop and we never invoke "git submodule--helper blah".
As a result, "git submodule--helper absorb-git-dirs" is probably the
only subcommand that prints its usage string (instead of the generic
"git submodule" usage string.)

It might be worth highlighting how absorbgitdirs is special in the
commit message, but I don't feel strongly either way.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux