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
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.
