"Cannot rebase onto multiple branches." when repeatedly using git pull

[trautwein]

General information

• Pure version: HEAD (master)
• ZSH version: 5.5.1 (x86_64-apple-darwin17.5.0)
• Terminal program & version: iTerm2 Build 3.1.6
• Operating system: macOS High Sierra 10.13.4 (17E202)
• ZSH framework: antibody 3.4.5

I have:

• Tested with another terminal program and can reproduce the issue: Terminal Version 2.8.2 (404)
• Followed the Integration instructions for my framework

Problem description

When repeatedly using git pull or the aliased gl I get the following error from git:
fatal: Cannot rebase onto multiple branches.

When waiting around 10 seconds in between executing git pull, the command works as intended.

I've only had this problem since a couple of weeks, so it might be a recent change in pure that broke this. Of course, it could also be a dependency or something else altogether.

Reproduction steps

1. cd into a git project folder
2. enter git pull
3. immediately enter git pull again

My .zshrc (stripped to bare minimum):

source /Users/trautwein/Library/Caches/antibody/https-COLON--SLASH--SLASH-git.luolix.top-SLASH-mafredri-SLASH-zsh-async/async.plugin.zsh
source /Users/trautwein/Library/Caches/antibody/https-COLON--SLASH--SLASH-git.luolix.top-SLASH-sindresorhus-SLASH-pure/pure.plugin.zsh
autoload -U promptinit; promptinit

[mafredri]

I've never run into this, and I can't reproduce using Git 2.17.0 (git --version) from Homebrew.

[trautwein]

Thanks for looking into it. I also use git 2.17.0 installed via Homebrew.

[mafredri]

Weird. Did you manage to reproduce this with your stripped down zshrc?

Could the git repo be in some weird state? Pure doesn't do anything special. It issues command git -c gc.auto=0 fetch when the prompt is shown and when you type git pull it will kill the fetch process which it initiated. I can't think of any changes that would affect this either, especially considering there hasn't been any changes to Pure in that department until 10 days ago. Version 1.7.0 was released 16 days ago, but the changes between 1.6.0 and 1.7.0 don't affect Git.

[mafredri]

If it was a commit that broke it, could you do a git bisect to find out which commit broke it for you?

[trautwein]

I bisected it using the stripped down .zshrc as seen above. The commit which broke it for me is a90b1bc

Commenting in and out parts of that commit, the setopt localtraps monitor causes the issue. See this line: a90b1bc#287

Edit: I realised that I'm not using the latest release tag (1.7.0) but the HEAD of master. Makes sense since the commit came after the release of 1.7.0.

[mafredri]

Thanks for tracking it down! It's curious that this happens to you, I have a very similar setup :/.

This is a bit of a wild guess, but does it help if you add hup, like so: setopt localtraps monitor hup?

Not even sure how to start debugging this, if this turns out to be a common problem, reverting #397 might be the only option :(.

[trautwein]

This is a bit of a wild guess, but does it help if you add hup, like so: setopt localtraps monitor hup?

Adding hup unfortunately doesn't help.

Not even sure how to start debugging this, if this turns out to be a common problem, reverting #397 might be the only option :(.

I'm on my work laptop right now, but I'll let you know if I have the same issue at home using my personal machine. I guess it will, but since you have a similar setup and don't run into this it might just be something on my work machine that's interfering.

If I can help in any way, let me know.

In case it helps, my dotfiles are here: https://github.com/neowork/dotfiles

[mafredri]

Thanks, setting pull mode in git config did the trick. I can now reproduce.

Turns out the implementation in #397 isn't allowing the async worker to flush it's job (it's used to kill the fetch to give room for your pull). So you have basically two concurrent git fetch/pull running, which is causing the error.

I'll try to come up with a solution, either reverting #397 or allowing the signals to propagate correctly while monitor mode is enabled.

[trautwein]

Awesome, thank you so much for your work!

[mafredri]

@trautwein care to give latest master a spin?

[trautwein]

Works perfectly! 🎉

[enewhuis]

I ran into this problem using direnv and submodules with git version 2.20.1 (Apple Git-117). My solution was to use an alias like git pull origin master --rebase, however, I am not sure which component of that command resolved the problem.

Apparently, the position of the --rebase flag at the end of the command string is important. If it turns out that I was fooled by temporal randomness then I will return here and update my findings.