I know how to solve this:
[email protected]$ 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
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.
For Git 2.6+ (released 28 Sept 2015)
git config setting which would be of interest is:
(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:
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.
pull: allow dirty tree when
rebase learned to stash changes when it encounters a dirty work tree, but
git pull --rebasedoes not.
Only verify if the working tree is dirty when
rebase.autostashis 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 (
(Merged by Junio C Hamano --
gitster -- in commit 7c137bb, 13 Apr 2016)
Commit f66398e in particular includes:
pull --rebase: add
rebase.autoStashconfiguration variable is set, there is no way to override it for "
git pull --rebase" from the command line.
git pull --rebase" the
--[no-]autostashcommand line flag which overrides the current value of
rebase.autoStash, if set. As "
git rebase" understands the
--[no-]autostashoption, 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.
--rebase --autostashworks in dirty repo
git pull --rebase --autostashin 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.
So everybody is writing about
autostashwhen you do rebase (or
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 --rebasebut OP asked about "standard" git pull
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:
pull-mergewere 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.autostashconfiguration 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 "
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:
- after finding it conflicts, run
git merge FETCH_HEADand
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
--ff-only is given (which would result a merge).
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.
pull.rebaseconfiguration 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-]rebaseoption from the command line and no
pull.rebaseconfiguration 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
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 (
(Merged by Junio C Hamano --
gitster -- in commit bf10200, 29 Apr 2020)
pull: pass --autostash to merge
Signed-off-by: Denton Liu
--autostashonly worked with
git pull --rebase.
However, in the last patch, merge learned
--autostashas well so there's no reason why we should have this restriction anymore.
Teach pull to pass
--autostashto merge, just like it did for rebase.
Signed-off-by: Denton Liu
builtin/rebase.cis similar enough to the
sequencer.cthat they are almost interchangeable, except for the type of arg they accept. Make the
sequencer.cversion extern and use it in rebase.
The rebase version was introduced in 6defce2b02 ("builtin rebase: support
--autostashoption", 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
Since both efforts are long done, we can freely combine them together now.
With Git 2.30 (Q1 2021), the UI is improved:
pull: colorize the hint about setting
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
This warning was clearly intended to advise users, but as pointed out in this thread, it uses
One consequence is that the advice is not colorized in the same manner as other, similar messages.
So let's use
With Git 2.33 (Q3 2021), git pull --rebase is simplified:
pull: cleanup autostash check
Signed-off-by: Felipe Contreras
Later on "
git merge" learned the
--autostashoption [a03b555 ("
--autostashoption", 2020-04-07, Git v2.27.0-rc0 -- merge listed in batch #5)], and so did "
git pull"(man) [d9f15d3 ("
--autostashto 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
Let's always take the fast-forward merge shortcut by essentially reverting f15e7cf.
To save few seconds for oncoming explorers, here is a summary (thanks to @VonC):
git pull --rebase --autostash
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'
Of course, this alias can be renamed as desired.
With Git 2.6+ you can use the following:
alias gup='git -c rebase.autoStash=true pull --rebase'
--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.
As you already mentioned this is the way to do it. You can use it in alias to save you typing and to use shortcut or you can use it in a single line (can be an alias as well)
git stash && git pull --rebase && git stash pop
It will do the same thing as you done but in a single line (&&) and is you set as alias it will even be shorter.
The following lines will display the incoming/outgoing changes before you pull/push
git log ^master origin/master git log master ^origin/master