-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable vcsh ls-file to take an option '-p' #285
Conversation
What heuristic should we aim for with spacing? Currently this turns
into
i.e. the removed spacing in front is different. There seem to be two options:
|
My preference would be to not trim any space at all and always add |
vcsh
Outdated
GIT_DIR=$VCSH_REPO_D/$VCSH_REPO_NAME.git; export GIT_DIR | ||
use | ||
$command_prefix "$@" | ||
$command_prefix "$@" | eval $command_suffix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't feel right to me, I think we can probably do better with an exec
call before running the command to setup the output stream processing. That would avoid piping everything through cat
even when this option is not active, hence not potentially breaking existing possibilities.
vcsh
Outdated
if [ x"$1" = x'-g' ]; then | ||
unset command_prefix | ||
fi | ||
if [ x"$1" = x'-p' ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method of option parsing just doesn't work right at all, you can't use -g -p
or -p -g
because the manual shift is eating the argument and throwing getopts()
off. Speaking of which, this isn't how getopts()
is supposed to work at all, and the flag variable it sets is being ignored. I don't know how the top level option parsing got away with this for so long, but I don't think it's correct either....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See also #286 for a PR that fixes the getopts()
usage for the main script.
6e488c8
to
87c12fe
Compare
I think I'm okay with this now. It's not quite as elegant as I would have liked, but it should be robust and the repetition is just because POSIX is more limiting than the ZSH scripting I'm used to.
|
I still hate the tab in front of getops long is a pain with POSIX, else I would prefer a long-opt. I wonder if it makes sense to keep |
I don't like it either, but that's on Git not us. If we start down the road trying to sanitize output from other commands according to the way we want to see it we'll never come out alive. This way (prefixing the exact full line) is reversible, the user could choose to parse it (say with
Yes, we have no good solution for long opts or I would go that route too. I can see wanting to keep Here's the deal though, I just realized this |
This PR isn't any more broken than it already was. In order to use the existing I suggest we go ahead and put this through knowing it only works without any top level flags and work on fixing that snafu separately. As such I can't think of any good reason not to use lower case |
I tested this for #286 and it works, though:
(this reminded me of how brittle my "what version are you" system is, and means I will need to fix it for the safe harbor release. Good thing I currently have a |
For now I sugges tagging a new safe harbor release as a new commit with the current one as its parent, then we'll merge that back into |
Amending my previous comment, I actually don't think you need to do anything with the safe harbor release at all. That was a freeze frame as Git HEAD existed and identified itself not a full release cycle as might otherwise have been. I don't think the fact that it identifies itself the same way cb33546 did is really that much of a problem. It's more obnoxious to me that the current HEAD builds still identify the same way and hence its useless for debugging, but I'll fix that soon enough with some build tooling. If you do add a tag, lets make it a commit branched from dbc9c07 that fixes VERSION in the script, then tag it v1.20190619.1. Then we can merge that back into master without too much fuss. If you want me to make it happen I can. But again I think it's okay to just leave it and work towards a v2.0.0. |
I don't understand how you are getting that result. Here is what I get: $ git checkout 78a05e1a
HEAD is now at 78a05e1 Fix broken getopts() usage, allows multiple flags
$ git reset --hard
HEAD is now at 78a05e1 Fix broken getopts() usage, allows multiple flags
$ git clean -dxff
$ ./vcsh -v foreach -g echo foo
verbose mode on
vcsh 1.20141026
vcsh: verbose: foreach begin
que-atom:
git: 'echo' is not a git command. See 'git --help'.
The most similar command is
fetch
que-awesome:
git: 'echo' is not a git command. See 'git --help'.
The most similar command is
fetch
... And so on with the same output for all of my repos. Is it possible that your Git is behaving differently than mine and passing unknown subcommands to the shell? Or that you have a |
Oh lovely. I just dried using $ dash vcsh -v foreach -g echo foo
verbose mode on
vcsh 1.20141026
vcsh: verbose: foreach begin
que-atom:
foo
que-awesome:
foo
... |
I think I'm going to go ahead and merge this. Fixing shell compatibility in option parsing is out of scope and this PR doesn't make it worse. |
Closes #247.
This is a re-submission of PR #252 which was closed automatically by the GitHub overloads when we renamed the default branch. Since the downstream fork no longer existed it closed rather than reparented some PRs, this being one of them.
Per my comments on the related issue I'm not sure this is the right approach, but if we do further work in this direction we can at least build on and attribute the commit.