Fish's handling of ^ still annoying to git users

[lmsurpre]

There was a change made in the past so that a caret '^' will only redirect stderr if it is the first character of a token:
#168

Today, I was trying to perform a multiple-point branch compare as described at
http://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#idp25327712

The '^' was the first syntax I used. I didn't understand why it wasn't working.
After experimenting with the options some more, I finally found my clue from the following error message from git:
"fatal: ambiguous argument 'staging': both revision and filename"

Fish was redirecting the stderr to a file with the name of my branch and so git was showing me just the log of the first branch instead of showing the difference.

Not sure if anything can/should be done about it, but thought I would report it anyway.

Also note that the same syntax is used in the rev-list command as mentioned by @aeosynth at #81 (comment)

[ridiculousfish]

Any ideas here are appreciated.

[hauleth]

Instead of ^ you can use ~. The only solution I see is to create builtin that will disable some special chars, but IMHO it will be über complicated.

[lmsurpre]

Or maybe "^" could only redirect when it is a standalone token?

[hauleth]

IMHO shell should use context free grammar

Łukasz Jan Niemier

Dnia 7 sty 2015 o godz. 15:31 lmsurpre notifications@github.com napisał(a):

Or maybe "^" could only redirect when it is a standalone token?

—
Reply to this email directly or view it on GitHub.

[ghost]

You can implement it that way with a context free grammar.

[ridiculousfish]

An example of the problematic syntax is git log ^refA refB

[hauleth]

That a^b, a ^b, a^ b and a ^ b will be different? I think not. You can use A~<n> (i.e. A^^^ is equal to A~3) in simple cases. In more complex cases it's better to use commit hash.

[rocketraman]

From the recently referenced duplicate issue which is a slightly different input than previously discussed here:

# git log 1608450^
Expected a string, but instead found end of the statement
fish: git log 1608450^

If the hash value contains non-numeric values, the command works fine:

git log c9ba59f^

[ridiculousfish]

This seems like a regression relative to #81

[ridiculousfish]

Now a number followed by a caret is never a redirection. Thanks for reporting this!