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

Fish's handling of ^ is very annoying for git users #168

Closed
lilyball opened this Issue Jun 21, 2012 · 13 comments

Comments

Projects
None yet
7 participants
@lilyball
Copy link
Contributor

lilyball commented Jun 21, 2012

The fact that Fish reserves ^ as a special character is extremely annoying for git users, because ^ is an incredibly common syntactical element in revision specifiers (e.g. HEAD^).

One possible solution would be to redefine Fish's handling of ^ to only treat it specially if it occurs at the beginning of its token. This way I can type HEAD^ without a problem but ^/dev/null would still work. This would be a slight incompatibility with the handling of </>, but given the popularity of Git I'd say it's worth it. Especially since people typically put a space before their redirection operators anyway.

@berdario

This comment has been minimized.

Copy link
Contributor

berdario commented Jun 22, 2012

As a workaround, you might use ~ instead of ^

In fact, I find ~ vastly more useful than ^:

with HEAD~2 you'll get the grandparent of HEAD, while with HEAD^2 you'll get the second parent of head (which exists only if HEAD is the result of a merge)

another possible workaround: simply wrap HEAD^ with quotes: "HEAD^"

@lilyball

This comment has been minimized.

Copy link
Contributor Author

lilyball commented Jun 22, 2012

By far the most common rev-list modifier that I use is ^, because the most common thing I want is access to an item's first parent. I would be very surprised if this was not true for most git users.

@berdario

This comment has been minimized.

Copy link
Contributor

berdario commented Jun 22, 2012

Exactly: HEAD~ lets you access the item's first parent

@lilyball

This comment has been minimized.

Copy link
Contributor Author

lilyball commented Jun 22, 2012

Hrm, I didn't realize that worked without the actual numeric specifier, e.g. HEAD~1. But that doesn't change the fact that every git user out there is already trained to use ^ to refer to the direct parent.

Incidentally, the git-rev-parse manpage only documents <rev>~<n> and does not document the <rev>~ form you're suggesting, which implies that the fact that it works is unintended/unspecified behavior.

@dmedvinsky

This comment has been minimized.

Copy link

dmedvinsky commented Jun 22, 2012

which implies that the fact that it works is unintended/unspecified behavior.

More like missing from the documentation, I reckon.

@jdelStrother

This comment has been minimized.

Copy link

jdelStrother commented Jun 22, 2012

I also ran into problems with git's curly bracket syntax - eg git checkout HEAD@{1}. Don't know if it's possible to do anything about that, other then always remembering to backslash-escape the brackets. In zsh, I had alias git=noglob git to work around zsh's globbing characters.

@siteshwar

This comment has been minimized.

Copy link
Member

siteshwar commented Jun 22, 2012

You can always put strings inside double quotes to avoid fish interpreting special characters. But let's see if we could figure out a better way to avoid annoyance with special characters.

@lilyball

This comment has been minimized.

Copy link
Contributor Author

lilyball commented Jun 22, 2012

Bash's solution to the HEAD@{1} problem is it doesn't treat braces as special unless there's a comma inside them. Unfortunately, Fish decided that the brace syntax was ideal for separating a variable from non-variable alphabetic text that follows, e.g. {$foo}bar, which means it has to interpret the braces specially even if there's no comma inside. This turns out to be rather unfortunate for anyone who actually wants braces in their normal text, e.g. git users. I'm not sure what solution Fish could have here besides making a wholly backwards-incompatible change to treat braces the same way Bash does. Note that such a change would still leave a separate way of splitting a variable from alphabetic text that follows, by putting a pair of quotes between them, as in $foo''bar.

As a side note, I always thought {$foo}bar was a really weird solution to the problem. It's awkward, non-obvious, and doesn't work when you're inside double-quotes. If I have "$foo" and I want to put bar on the end, my only solution there is to terminate the quotes, as in "$foo"bar (or "$foo""bar"). So it turns out that changing conventions to using $foo''bar would actually be more closely aligned with how you deal with this inside of double-quotes.

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jul 9, 2012

kballard's suggestion of making ^ only significant at the beginning of a token seems reasonable to me. I too find the interaction with git to be quite the annoyance.

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jul 9, 2012

If anyone wants cares to take a crack at implementing this I'll be happy to merge it for the next release; otherwise it's in fish-future.

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jul 11, 2012

I changed my mind and fixed this. Now ^ only acts as a redirection at the beginning of a token, so git checkout HEAD^ works without quoting.

To git@github.com:fish-shell/fish-shell.git
11dd904..4ee1cc3 master -> master

@lilyball

This comment has been minimized.

Copy link
Contributor Author

lilyball commented Jul 11, 2012

Awesome, thanks!

@martinklepsch

This comment has been minimized.

Copy link

martinklepsch commented Aug 3, 2012

#81 seems to be a dupe of this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment