4

I want to pull changes into my working copy but git won't let me, I get the same error as this question:

Cannot rebase: Your index contains uncommitted changes.
Please commit or stash them.

I know that I can commit and then merge, or stash - then pull - then apply the stash, but previously a pull would merge changes into my working copy preserving my local changes. It was seamless, any conflicts would be marked up for me to resolve in my working copy, just like when merging committed changes. I found this very convenient, why has this behaviour changed? And how can I make git behave like that again?

Community
  • 1
  • 1
jhabbott
  • 18,461
  • 9
  • 58
  • 95

2 Answers2

2

Cannot rebase

That means you are not just pulling. you are doing a pull --rebase.
(Or, as Zeeker mentions in the comments, you have git configured to always do a pull --rebase, for example via git config pull.rebase true)

And if you want to automatically stash (and re-apply) your work in progress, you can check if that works with (Git 2.0.1+, July 2014) a:

git config rebase.autostash true

See more with "Git - How to edit old (not previous) commit with some of the unstaged changes from current index (current state)?"

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • This is great information, though I'm currently using 1.9.3 and this isn't working for me, nor is --autostash. However, I want to know why the behaviour changed... was 'autostash' implicit before? Has the default pull behaviour/implementation changed such that autostash is now required whereas it wasn't before? Am I remembering the old behaviour wrong? I can work around the issue now, or update git and use the autostash feature, etc. but my question is more about "something changed - there's probably a good reason for it - I don't get it - so why?" :) – jhabbott Dec 18 '14 at 12:25
  • @jhabbott no sure. It might have worked before because you were pulling only (merge) and not rebasing. But I don't remember any changes, just the addition of that new feature. – VonC Dec 18 '14 at 12:29
  • @jhabbott By default a `git pull` merges your changes. So either you have used `git pull --rebase` or you have git configured to always do a `pull --rebase` (for example via `git config pull.rebase true`). – Sascha Wolf Dec 18 '14 at 12:31
  • @Zeeker I forgot about that config: I have included in the answer for more visibility. – VonC Dec 18 '14 at 12:36
  • @VonC I've added an answer which explains how to disable such a configuration. I think both solutions are valid. – Sascha Wolf Dec 18 '14 at 12:37
  • @jhabbott I agree something has changed. I was always using pull --rebase. In the last month or so autostash stopped working. – Sam Brightman Jan 12 '15 at 14:26
2

It seems like you have configured git to always do a git pull --rebase. There are multiple configurations which lead to this behaviour. I'll quote from the documentation:

See pull.rebase, branch.<name>.rebase and branch.autosetuprebase in git-config if you want to make git pull always use --rebase instead of merging.

If you want git to merge your changes instead of rebasing them when you pull you have to find the culprit configuration and disable it.

If the pull.rebase configuration was enabled globally for example you could disable it with the following command:

git config  --global --unset pull.rebase
Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73
  • Ahh - I'm using SourceTree configured for GitFlow, it has set up the `branch..rebase` config setting you mentioned. So this is causing the rebase. – jhabbott Dec 18 '14 at 13:01
  • I didn't see your answer right away. I would obviously have edited mine to add that simple config setting but since you posted a separate answer to what I described, +1 – VonC Dec 18 '14 at 13:03