heroku updated its command suggestion formatting, so account for that.
For example:
$ heroku log
▸ log is not a heroku command.
▸ Perhaps you meant logs?
▸ Run heroku _ to run heroku logs.
▸ Run heroku help for a list of available commands.
$ fuck
heroku logs [enter/↑/↓/ctrl+c]
For example, if an "etl" script is defined in package.json, it can be
run with `yarn etl`. However, if `yarn etil` is run, `yarn` will
suggest the correction. This change lets `thefuck` take advantage of
that:
$ yarn etil
yarn etil v0.21.3
error Command "etil" not found. Did you mean "etl"?
$ fuck
yarn etl [enter/?/?/ctrl+c]
Yarn likes to keep its documentation online, rather than in `yarn help`
output. For example, `yarn help clean` doesn't tell you anything about
the `clean` subcommand. Instead, it points you towards
https://yarnpkg.com/en/docs/cli/clean
This rule detects when that happens, and suggests opening the URL. One
caveat is the currently only OSX is supported, as Linux uses `xdg-open`
instead of `open`.
* remove comments/doctrings at the top of files;
* move sudo-related stuff to sudo rule;
* for no_command case try to find most similar command, like, for example, in react_native_command_unrecognized rule.
This adds `--force` to `git add` when needed. For example:
$ git add dist/*.js
The following paths are ignored by one of your .gitignore files:
dist/app.js
dist/background.js
dist/options.js
Use -f if you really want to add them.
$ fuck
git add --force dist/app.js dist/background.js dist/options.js [enter/↑/↓/ctrl+c]
$
This adds `--force` to `git tag` when needed. For example:
$ git tag alert
fatal: tag 'alert' already exists
$ fuck
git tag --force alert [enter/↑/↓/ctrl+c]
Updated tag 'alert' (was dec6956)
$
When there are local changes to a file, and a git stash is popped that
contains other changes to that same file, git fails as follows:
$ git stash pop
error: Your local changes to the following files would be overwritten by merge:
src/index.js
Please commit your changes or stash them before you merge.
Aborting
$
This change adds a rule that corrects this problem as suggested [here]:
$ git stash pop
error: Your local changes to the following files would be overwritten by merge:
src/index.js
Please commit your changes or stash them before you merge.
Aborting
$ fuck
git add . && git stash pop && git reset . [enter/↑/↓/ctrl+c]
Auto-merging src/index.js
On branch flow
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: src/index.js
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: src/index.js
Dropped refs/stash@{0} (f94776d484c4278997ac6837a7b138b9b9cdead1)
Unstaged changes after reset:
M src/index.js
$
[here]: https://stackoverflow.com/questions/15126463/how-do-i-merge-local-modifications-with-a-git-stash-without-an-extra-commit/15126489#15126489
This is to help address bad corrections like the following (note the
position of the -p flag):
thefuck 'git log $(git ls-files thefuck | grep python_command) -p'
git log $(git ls-files thefuck | grep -p python_command) [enter/↑/↓/ctrl+c]
These were found by creating a `.flake8` file containing:
[flake8]
ignore = E501,W503
exclude = venv
then running:
flake8 $(git diff master... --name-only)
See https://github.com/nvbn/thefuck/pull/563 for running `flake8` in CI
For example:
$ git log README.md -p
fatal: bad flag '-p' used after filename
$ fuck
git log -p README.md [enter/↑/↓/ctrl+c]
Aborted
$ git log -p README.md --name-only
fatal: bad flag '--name-only' used after filename
$ fuck
git log -p --name-only README.md [enter/↑/↓/ctrl+c]
Aborted
$ git log README.md -p CONTRIBUTING.md
fatal: bad flag '-p' used after filename
$ fuck
git log -p README.md CONTRIBUTING.md [enter/↑/↓/ctrl+c]
Suggest `foo --help` instead. However, if there are man pages, suggest
`foo --help` after `man 2/3 foo`
This addresses the comment in the previous commit message:
> However, in cases where multiple sections have man pages for `foo`,
> running `man foo` could bring up the "wrong" section of man pages.
> `man read` is an example of this, but that should probably be handled in
> a way that still suggests `foo --help` first when there are *no* man
> pages for `foo` in any section.
`man` without a section searches all sections, so having `foo --help`
suggested first makes more sense than adding a specific section. See
https://github.com/nvbn/thefuck/pull/562#issuecomment-251142710
However, in cases where multiple sections have man pages for `foo`,
running `man foo` could bring up the "wrong" section of man pages.
`man read` is an example of this, but that should probably be handled in
a way that still suggests `foo --help` first when there are *no* man
pages for `foo` in any section.
Closes https://github.com/nvbn/thefuck/issues/546
This is along the lines of what @waldyrious suggested in
https://github.com/nvbn/thefuck/issues/546, but it just adds a new
suggestion rather than replacing the other ones.
