Can "git pull" automatically stash and pop pending changes?

Question

I know how to solve this:

user@host$ git pull
Updating 9386059..6e3ffde
error: Your local changes to the following files would be overwritten by merge:
    foo.bar
Please, commit your changes or stash them before you can merge.
Aborting

But isn't there a way to let git pull do the stash and pop dance for me?

If this command has a different name, it's ok.

Creating a shell alias for git stash; git pull; git stash pop is a solution, but I search for a better solution.

Solution 1

For Git 2.6+ (released 28 Sept 2015)

The only git config setting which would be of interest is:

rebase.autostash

(with Git 2.27, Q2 2020, you now also have merge.autostash, see below)

When set to true, automatically create a temporary stash before the operation begins, and apply it after the operation ends.
This means that you can run rebase on a dirty worktree.

However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts. Defaults to false.

Combine that with:

pull.rebase

When true, rebase branches on top of the fetched branch, instead of merging the default branch from the default remote when "git pull" is run.

In a given repository:

git config pull.rebase true
git config rebase.autoStash true

That would be enough for a simple git pull to work even in a dirty tree.
No alias needed in that case.

---

See commit 53c76dc (04 Jul 2015) by Kevin Daudt (Ikke).
^{(Merged by Junio C Hamano -- gitster -- in commit e69b408, 17 Aug 2015)}

pull: allow dirty tree when rebase.autostash enabled

rebase learned to stash changes when it encounters a dirty work tree, but git pull --rebase does not.

Only verify if the working tree is dirty when rebase.autostash is not enabled.

---

Note: if you want to pull without autostash (even though rebase.autoStash true is set), you have since git 2.9 (June 2016):

 pull --rebase --no-autostash

See commit 450dd1d, commit 1662297, commit 44a59ff, commit 5c82bcd, commit 6ddc97c, commit eff960b, commit efa195d (02 Apr 2016), and commit f66398e, commit c48d73b (21 Mar 2016) by Mehul Jain (mehul2029).
^{(Merged by Junio C Hamano -- gitster -- in commit 7c137bb, 13 Apr 2016)}

Commit f66398e in particular includes:

pull --rebase: add --[no-]autostash flag

If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line.

Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the --[no-]autostash option, it's just a matter of passing the option to underlying "git rebase" when "git pull --rebase" is called.

---

Warning: before Git 2.14 (Q3 2017), "git pull --rebase --autostash" didn't auto-stash when the local history fast-forwards to the upstream.

See commit f15e7cf (01 Jun 2017) by Tyler Brazier (tylerbrazier).
^{(Merged by Junio C Hamano -- gitster -- in commit 35898ea, 05 Jun 2017)}

pull: ff --rebase --autostash works in dirty repo

When git pull --rebase --autostash in a dirty repository resulted in a fast-forward, nothing was being autostashed and the pull failed.
This was due to a shortcut to avoid running rebase when we can fast-forward, but autostash is ignored on that codepath.

---

Update: Mariusz Pawelski asks in the comments an interesting question:

So everybody is writing about autostash when you do rebase (or pull --rebase).

But no one is taking about autostashing when you do normal pull with merges.
So there is no automatic switch for that? Or I am missing something? I prefer doing git pull --rebase but OP asked about "standard" git pull

Answer:

The original thread discussing this autostash feature, it was implemented originally both for git pull (merge) and git pull --rebase.

But... Junio C Hamano (Git maintainer) noted that:

If the pull-merge were something that would induce the "annoyance" that triggered this topic, by definition, the local change overlaps with the merge, and this internal "stash pop" will touch the paths the merge touched and it is likely not result in "Dropped" but leave further conflicts to be resolved.

I suspect that pull.autostash configuration is not a good addition because it encourages a bad, pain-inducing workflow.
In simple cases it may not hurt, but when local changes are complex, it would actively hurt than not having it, and the configuration robs the incentive to choose.

The equation is somewhat different for "pull-rebase", as "rebase" insists you to start from a clean working tree, so "download and then stop" annoyance feels bigger. I have a suspicion that loosening that may be a more productive fix to the real problem.

So, regarding a classic pull-merge, it is better to:

encourage the user to think about the nature of WIP he has in the working tree before running "git pull".
Is it a too complex beast that may interfere with what others are doing, or is it a trivial change that he can stash away and pop it back?

If the former, he will be far better off doing "checkout -b", keep working until the local change gets into somewhat a better shape and "commit", before pulling into the original branch.

If the latter, he is better off doing:

• "git pull",
• after finding it conflicts, run
  • git stash,
  • git merge FETCH_HEAD and
  • git stash pop

---

That being said, with Git 2.27 (Q2 2020), "git pull" learned to warn when no pull.rebase configuration exists, and neither --[no-]rebase nor --ff-only is given (which would result a merge).

See commit d18c950 (10 Mar 2020) by Alex Henrie (alexhenrie).
^{(Merged by Junio C Hamano -- gitster -- in commit 1c56d6f, 27 Mar 2020)}

pull: warn if the user didn't say whether to rebase or to merge

^{Signed-off-by: Alex Henrie}

Often novice Git users forget to say "pull --rebase" and end up with an unnecessary merge from upstream.

What they usually want is either "pull --rebase" in the simpler cases, or "pull --ff-only" to update the copy of main integration branches, and rebase their work separately.
The pull.rebase configuration variable exists to help them in the simpler cases, but there is no mechanism to make these users aware of it.

Issue a warning message when no --[no-]rebase option from the command line and no pull.rebase configuration variable is given.
This will inconvenience those who never want to "pull --rebase", who haven't had to do anything special, but the cost of the inconvenience is paid only once per user, which should be a reasonable cost to help a number of new users.

---

With Git 2.27 (Q2 2020), "git merge" learns the "--autostash" option, and the new merge.autostash setting.

See commit d9f15d3, commit f8a1785, commit a03b555, commit 804fe31, commit 12b6e13, commit 0dd562e, commit 0816f1d, commit 9bb3dea, commit 4d4bc15, commit b309a97, commit f213f06, commit 86ed00a, commit facca7f, commit be1bb60, commit efcf6cf, commit c20de8b, commit bfa50c2, commit 3442c3d, commit 5b2f6d9 (07 Apr 2020), commit 65c425a (04 Apr 2020), and commit fd6852c, commit 805d9ea (21 Mar 2020) by Denton Liu (Denton-L).
^{(Merged by Junio C Hamano -- gitster -- in commit bf10200, 29 Apr 2020)}

pull: pass --autostash to merge

^{Signed-off-by: Denton Liu}

Before, --autostash only worked with git pull --rebase.

However, in the last patch, merge learned --autostash as well so there's no reason why we should have this restriction anymore.
Teach pull to pass --autostash to merge, just like it did for rebase.

And:

rebase: use apply_autostash() from sequencer.c

^{Signed-off-by: Denton Liu}

The apply_autostash() function in builtin/rebase.c is similar enough to the apply_autostash() function in sequencer.c that they are almost interchangeable, except for the type of arg they accept. Make the sequencer.c version extern and use it in rebase.

The rebase version was introduced in 6defce2b02 ("builtin rebase: support --autostash option", 2018-09-04, Git v2.20.0-rc0 -- merge listed in batch #8) as part of the shell to C conversion.
It opted to duplicate the function because, at the time, there was another in-progress project converting interactive rebase from shell to C as well and they did not want to clash with them by refactoring sequencer.c version of apply_autostash().
Since both efforts are long done, we can freely combine them together now.

---

With Git 2.30 (Q1 2021), the UI is improved:

See commit e01ae2a (19 Nov 2020) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 290c940, 30 Nov 2020)}

pull: colorize the hint about setting pull.rebase

^{Pointed-out-by: Ævar Arnfjörð Bjarmason
Signed-off-by: Johannes Schindelin}

In d18c950a69f ("pull: warn if the user didn't say whether to rebase or to merge", 2020-03-09, Git v2.27.0-rc0 -- merge listed in batch #2), a new hint was introduced to encourage users to make a conscious decision about whether they want their pull to merge or to rebase by configuring the pull.rebase setting.

This warning was clearly intended to advise users, but as pointed out in this thread, it uses warning() instead of advise().

One consequence is that the advice is not colorized in the same manner as other, similar messages.
So let's use advise() instead.

---

With Git 2.33 (Q3 2021), git pull --rebase is simplified:

See commit a7d18a1, commit a751e02, commit 3400622 (17 Jun 2021) by Felipe Contreras (felipec).
^{(Merged by Junio C Hamano -- gitster -- in commit 221ec24, 08 Jul 2021)}

pull: cleanup autostash check

^{Signed-off-by: Felipe Contreras}

Currently "git pull --rebase"^(man) takes a shortcut in the case a fast-forward merge is possible; run_merge() is called with --ff-only.

However, "git merge"^(man) did ont have an --autostash option, so, when "git pull --rebase --autostash``"^(man) was called and the fast-forward merge shortcut was taken, then the pull failed.

This was fixed in commit f15e7cf ("pull: ff --rebase --autostash works in dirty repo", 2017-06-01, Git v2.14.0-rc0 -- merge listed in batch #7) by simply skipping the fast-forward merge shortcut.

Later on "git merge" learned the --autostash option [a03b555 ("merge: teach --autostash option", 2020-04-07, Git v2.27.0-rc0 -- merge listed in batch #5)], and so did "git pull"^(man) [d9f15d3 ("pull: pass --autostash to merge", 2020-04-07, Git v2.27.0-rc0 -- merge listed in batch #5)].

Therefore it's not necessary to skip the fast-forward merge shortcut anymore when called with --rebase --autostash.

Let's always take the fast-forward merge shortcut by essentially reverting f15e7cf.

Solution 2

To save few seconds for oncoming explorers, here is a summary (thanks to @VonC):

git pull --rebase --autostash

Solution 3

As the comment above stated, setting the two config values doesn't currently work with git pull, as the autostash config only applies to actual rebases. These git commands do what you want:

git fetch
git rebase --autostash FETCH_HEAD

Or set it as an alias:

git config alias.pullr '!git fetch; git rebase --autostash FETCH_HEAD'

Then do:

git pullr

Of course, this alias can be renamed as desired.

Solution 4

With Git 2.6+ you can use the following:

alias gup='git -c rebase.autoStash=true pull --rebase'

This --rebase makes git-pull use rebase instead of merge, so settings/options like --ff-only won't apply.

I am using an alias to pull with --ff-only by default (git pull --ff-only), and can then use gup (from above) in case a fast-forward merge is not possible or there are stashed changes.

View more solutions

Comments

[Яois]

what about a git alias?

[jub0bs]

Running git stash; git pull; git stash pop programmatically is dangerous, because if there is nothing to stash, git stash will be a no-op, but git stash pop will pop the last stash (if any), which is almost certainly not what you want. User torek has a great post about this on Stack Overflow, but I can't find it...

[VonC]

@Jubobs this one? stackoverflow.com/a/20412685/6309 Or this one? stackoverflow.com/a/20480591/6309

[guettli]

@VonC I checked both questions, and I don't think this question (mine) is a duplicate.

[jub0bs]

@VonC One of those :) Thanks.

[VonC]

@guettli I was not implying your question is a duplicate, I was just answering Jubobs' comment.

[Ed Avis]

As a step further, the operation should succeed only if the stash can be cleanly applied after the pull. If there are conflicts, then the whole operation fails atomically so that the tree is not changed. This is what I would like to do: either pull down the changes with my local ones merged in, or else fail with an error and let me decide manually what to do next. Is this kind of git 'transaction' possible?

[VonC]

You now have git config merge.autostash, if you want to pull without rebasing (while stashing your local changes automatically). See my edited answer below

[Randal Schwartz]

As of 2.4.2, this is not implemented yet. Perhaps some day. rebase.autoStash applies only when using rebase. pull.rebase applies only when using pull.

[Pradhan]

"That would be enough for a simple git pull to work even in a dirty tree." As Randal commented, this isn't true yet. The current master's pull.c still chooses to die_on_unclean_work_tree.

[VonC]

@Pradhan I agree. The implementation just got in master this morning and should be up for git 2.6. I have edited the answer to make that clear.

[VonC]

The point is: after a git config pull.rebase true and git config rebase.autoStash true, all you'll ever need is git pull. Just git pull. No other options required.

[Joshua Hoblitt]

I have confirmed that autostash is working with git 2.5.5.

[ntc2]

Appears you need at least Git 2.9 for the --autostash option. The -c rebase.autoStash=true works in Git 2.6 onward.

[John Zwinck]

This approach is unsafe: if there's nothing to stash, the first command will do nothing, and then stash pop will unstash some random stuff from before.

[Abhinav Parab]

SVN will do all that automatically.

[Mariusz Pawelski]

So everybody is writing about autostash when you do rebase (or pull --rebase). But no one is taking about autostashing when you do normal pull with merges. So there is no automatic switch for that? Or I am missing something? I prefer doing git pull --rebase but OP asked about "standard" git pull

[VonC]

@MariuszPawelski Very interesting question. I have edited my answer to explain why there is no autostash for a regular git pull (merge).

[MoonLite]

Just to be extra clear: even if git stash does not stash anything it still "returns" no errorcode so the && will still continue with git pull and git stash pop and pop a previous stash. So better not use this unless you are very certain it will stash something!

[alper]

What is the main difference between git pull --ff-only and git pull pull --rebase --autostash

[Iulian Onofrei]

Any idea how to make this work with untracked files too?

[VonC]

@IulianOnofrei could you add more details to your comment, in a separate question? That will be more visible than here, buried in comments.