git push upstream branch does not exist, wrong command recommended first

[matthewarmand]

Recently I noticed a change in a thefuck behavior that I use very regularly which I wanted to call out as what I think is an unwanted change. This was introduced very recently, I believe with the 3.31 release. When using git push on a git repository where the branch does not exist in the upstream repository, git responds with a specific command one should run to create the upstream branch. Prior to version 3.31, thefuck seemed to recognize this and made the first suggested Corrected Command was the one git recommended. As of version 3.31, thefuck instead puts a generic git push --no-verify command first, and the one git recommended is instead the second result.

In this case where git recommends a specific command, git push --no-verify doesn't actually help or do what the user wants; you need the git push --set-upstream origin branch-name command which thefuck now arrives at second. Because of the inconvenience for this particular case, combined with the fact that the first option recommended by thefuck isn't functionally valid, the prior behavior is more correct for this particular case.

Below is all the debug information requested in the issue template:

The output of thefuck --version (something like The Fuck 3.1 using Python 3.5.0 and Bash 4.4.12(1)-release):

The Fuck 3.31 using Python 3.9.5 and ZSH 5.8

Your system (Debian 7, ArchLinux, Windows, etc.):

Arch Linux

How to reproduce the bug:

- In a git repo, create a branch which does not exist in the upstream repository
- Attempt to push the branch with `git push`
- You should see an error message saying "fatal: The current branch branch-name has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin branch-name"
- invoke `thefuck`
- Prior to 3.31, `thefuck` would present as the first option the exact command which git tells you to use (git push --set-upstream origin branch-name).
- As of 3.31, `thefuck` instead presents as the first option a more generic `git push --no-verify`, and git's recommended command is the second result.

The output of The Fuck with THEFUCK_DEBUG=true exported (typically execute export THEFUCK_DEBUG=true in your shell before The Fuck):

https://pastebin.com/qpyEcreC

If the bug only appears with a specific application, the output of that application and its version:

git version 2.32.0

Anything else you think is relevant:

N/A

[hamidnazari]

This is the culprit: 39753a0

Seems like as long as you've run git commit, git am, or git push thefuck's first suggestion is [whatever you ran] --no-verify, even ignoring what git is suggesting!

Have no idea what's the logic behind prioritising a suggestion that in most cases is not a very good suggestion.
Optimisation? #1097 (comment)
Edit: simply an incorrect priority value.

Edit: PR #1208 fixes this problem. Waiting for it to be merged!

[nejsimon]

Same issue here after upgrading from 3.30 to 3.31 (mac os 11.4, installed using homebrew).

[godbout]

👀️

[hamidnazari]

As a workaround, until the fix is merged and package repos updated which seems will take a while, do this,

UPDATED:
Add this env var to your shell sessions, i.e. put it in .bash_profile or equivalent file on your system.

export THEFUCK_PRIORITY="git_hook_bypass=1100"

OLD:
Find your thefuck's installation location and this file in there: ./thefuck/rules/git_hook_bypass.py
edit it and change the priority value from 900 to 1100. Your next update should replace this patch.

I've used Homebrew on Mac to install thefuck, so for me this works:

$ sed -i.bak 's/priority = 900/priority = 1100/' /usr/local/Cellar/thefuck/3.31/libexec/lib/python3.9/site-packages/thefuck/rules/git_hook_bypass.py

[scorphus]

That was a very unfortunate choice for a priority. Thanks @matthewarmand for filing the issue and @hamidnazari for identifying the problem and fixing it!

[matthewbal]

I upgraded a homebrew cask yesterday and suddenly thefuck stopped recommending the push --set-upstream branch too. Fix posted by @hamidnazari worked instantly, and good to hear that the proper fix is already coming soon. Thanks for the great work on this project guys!

[Voldiemert]

Commenting just to follow for the fix. Using the workaround too. Thanks!

[matthewarmand]

Commenting just to follow for the fix

Friendly tip, in the future you could consider following issues in a less noisy way by subscribing to issue notifications:

Additionally, since this issue is closed and the associated PR merged I'm not sure you'll actually get a notification when the fix is released. You could subscribe to notifications on related issue #1219, which maintainers said they'll leave open to track the release. Another (potentially more useful?) method is to use Github's "Watch" feature on the repo to subscribe just to Releases until the next one comes out.

[vilmosnagy]

is there a plan to release this fix?

this was one of the most useful usages of this command, and I'm not able to use it since a month or so. 😢

[scorphus]

Yes, there is plan! Please bear with us while we squeeze time on our ends 😊😁 We're getting there!

For now, there is one issue left to fix and one pull request left to review. The issue is being taken care of and PR reviews are always more than welcome 🙂

[adamdavis40208]

Any update on releasing this? Workaround works, just curious

[josmo]

Looks like it was just released /~https://github.com/nvbn/thefuck/releases/tag/3.32 which includes the fix for this