what are the pull.rebase false & pull.ff true differences?-CodePudding

is there any difference in using

git config pull.rebase false     # merge (the default strategy)

and

git config pull.ff true

both commands fast-forwards if possible, and if it's not merge.

Which config should I use?

CodePudding user response：

While both these settings act on how git pull should behave when git, during a git pull, has to reconcile changes in your local branch with changes, they don't turn the same knob.

pull.ff can be set to false | true | only. It matches the cli options : --no-ff | --ff | --ff-only, and if any of these cli options is passed when you run git pull, the config setting is overlooked.

If set to only, git pull will refuse to do anything if the remote branch is not straight ahead of your local branch, so the pull.rebase setting will never kick in -- unless the config setting is overridden by a flag on the command line.

pull.rebase can be set to false | true | interactive | merges. It matches the cli options --rebase[=false|true|merges|interactive].

If it is set to something that says "use rebase to combine the changes" (e.g: true|interactive|merges), then a setting stating --ff or --no-ff has no effect -- there won't be a merge anyway.

what should I use ?

This question depends on context -- for example : if your work has a workflow which favors one action specifically, set the defaults to that action ; if you are used to a specific sequence of actions, set the defaults to your usage.

Instead of answering your question, I will describe how I work :

I personally don't like using git pull, because you get in one go "get the changes you don't know of from the central repo, and merge them with your work", without a chance to review the changes between the two steps.

I generally run :

git fetch
git log --graph --oneline origin/master my/branch (e.g : inspect the state of the remote branch I'm interested in)
run either git rebase origin/master or git merge origin/master (we happen to have a workflow which favors rebase, but anyways : I already have an idea of how complicated that action is going to be)

the difference with git pull is that at step 3, I can do :

merge or rebase an intermediate commit of the remote branch , or an intermediate commit on my own branch,
cherry-pick a specific commit to see what mess it would introduce,
edit my branch before rebasing/merging (one common case: drop that commit which does almost the same thing as the bugfix added on master)
...

I have also set an alias for pull --ff-only, since that one is "harmless" (e.g: you know git will not mess up your code if you run it, it will either do the trivial thing or stop and say "this is not a fast-forward"), and use it to update branches which are not mine.

CodePudding user response：

both commands fast-forwards if possible

Actually, pull.ff will refuse to pull if the tip of the current branch cannot be fast-forwarded, when the setting is set to only.

While pull.rebase simply instructs pull to make a merge (fast-forward or not).

Personally, I always use git config --global pull.rebase true in order to rebase (replay) my local commits (not yet pushed) on top of the refreshed remote tracking branch.

what's the point of having to similar commands

Because both settings achieve different goals:

set pull.ff to only disallows fast-forward pull: it is what to do on a merge pull.
if pull.rebase is set to true, then pull.ff does not matter: if is about what to do on a pull (merge? or rebase?)