4

Following question Can “git pull” automatically stash and pop pending changes has solutions using both:

  • git pull --rebase --autostash

  • git pull --ff-only

I am little bit confused about which one should I use. Do they actually accomplish same result? Very similiar question is asked which does not has --autostash parameter along with the --rebase

alper
  • 2,919
  • 9
  • 53
  • 102
  • `git pull --ff-only` can success only if local or remote has changed, if there is commit on both local and remote this will trigger an error. – Ôrel Jun 30 '20 at 14:24

1 Answers1

7

Imagine a situation where the remote has changes you don't:

remote | A - B - C - D - E
       |
local  | A - B - C

Here you can git pull --ff-only, because it's possible to fast-forward from C to E. Now imagine you've also made changes:

remote | A - B - C - D - E
       |
local  | A - B - C - F - G

If you git pull --ff-only, it will be rejected, because you can't fast-forward from G to E; per the docs (emphasis mine):

With --ff-only, resolve the merge as a fast-forward when possible. When not possible, refuse to merge and exit with a non-zero status.

There are two ways to solve this, either:

  • creating a merge commit (the default if a fast-forward isn't possible, or can be forced with --no-ff); or
  • rebasing (--rebase).

If you git pull --rebase, it will roll your local copy back to C, fast-forward to E, then replay F and G onto the new parent, leaving:

remote | A - B - C - D - E
       |
local  | A - B - C - D - E - F' - G'

--autostash is a separate argument, per the docs:

This means that you can run the operation on a dirty worktree.

In both cases above I assumed a clean worktree (i.e. git status shows "nothing to commit, working tree clean" - you have no uncommitted local changes), for simplicity's sake, but sometimes you might want to pull new changes while you have local work in progress.

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437