You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I run the git-cp script directly with no parameters, the output says USAGE: /foo/bar/bin/git-cp [...] which is on point. I might want it to just say git-cp there, but that's a minor quibble.
More importantly, and the subject of this issue, is that if I run git cp and git searches my path to find the git-cp script, then the output STILL says USAGE: /foo/bar/bin/git-cp [...] when I think it should say USAGE: git cp [...] in keeping with the behavior of most other git commands.
Some git command scripts included with git use different approaches for this:
git-archimport, git-cvsexportcommit, git-cvsimport, git-cvsserver, and git-merge-one-file all hard code the usage text of git whatever without regard for the actual filename
git-filter-branch, git-merge-one-file, git-mergetool, git-submodule, and git-web--browse all use git-sh-setup's usage() to parse the script filename and blindly removes the first dash
git-p4 does what git-extras does now, outputting the full path to the script
I propose one of the following solutions:
Hard code git foo as the usage invocation for git-foo across all the scripts
Use git-sh-setup's usage()
Implement a custom detection of git invocation, perhaps by checking for GIT_EXEC_PATH
I volunteer to implement any of these if you pick one.
The text was updated successfully, but these errors were encountered:
@spacewander Any suggestion on whether I pursue option 1, 2, or 3?
Also, how complete would such a change need to be to get accepted? I notice a lot of the git-extras scripts were written with different usage string paradigms already, probably copied from different upstream behaviors. Some of them will be easy to convert to use something more flexible. Others are already very complex and may be difficult to convert.
I have underestimated how many different usage output paradigms there would be in the different scripts here. This will be a bigger undertaking than I originally thought. I still want to do it, just not today.
If I run the
git-cp
script directly with no parameters, the output saysUSAGE: /foo/bar/bin/git-cp [...]
which is on point. I might want it to just saygit-cp
there, but that's a minor quibble.More importantly, and the subject of this issue, is that if I run
git cp
and git searches my path to find thegit-cp
script, then the output STILL saysUSAGE: /foo/bar/bin/git-cp [...]
when I think it should sayUSAGE: git cp [...]
in keeping with the behavior of most other git commands.Some git command scripts included with git use different approaches for this:
git-archimport
,git-cvsexportcommit
,git-cvsimport
,git-cvsserver
, andgit-merge-one-file
all hard code the usage text ofgit whatever
without regard for the actual filenamegit-filter-branch
,git-merge-one-file
,git-mergetool
,git-submodule
, andgit-web--browse
all usegit-sh-setup
'susage()
to parse the script filename and blindly removes the first dashgit-p4
does whatgit-extras
does now, outputting the full path to the scriptI propose one of the following solutions:
git foo
as the usage invocation forgit-foo
across all the scriptsgit-sh-setup
'susage()
GIT_EXEC_PATH
I volunteer to implement any of these if you pick one.
The text was updated successfully, but these errors were encountered: