Is git set 'git pull' with rebase by default for now? Which version when it start?

Question

In the past, git pull is doing git fetch and git merge.So it always have merge commit.

But now I saw our team members, use 'git pull' when they have commits. And won't have merge commit, because the commit time is later than the branch's last commit.

I have check the git config --list and it has rebase.autosquash=true.

Is git set git pull with rebase by default for now? Which version when it start?

question from:https://stackoverflow.com/questions/65948283/is-git-set-git-pull-with-rebase-by-default-for-now-which-version-when-it-star

Answer 1

In the past, git pull is doing git fetch and git merge.

This is still the default.

So it always have merge commit.

This, however, is not the case: git merge with no options defaults to doing a fast-forward operation instead of a merge, whenever this is possible. A fast-forward operation is not a merge (even though Git refers to it as a "fast-forward merge") so it does not produce a merge commit.

You get a merge commit when:

• you force git merge to make one, using --no-ff; or
• a fast-forward is not possible (in which case --no-ff, if you set it, is redundant).

This is all quite configurable, though.

But now I saw our team members, use 'git pull' when they have commits. And won't have merge commit, because the commit time is later than the branch's last commit.

The word because here is misplaced. The time stamps on any given commit are quite independent of whether Git uses a merge commit. There is no cause-and-effect relationship here. Merging uses the commit graph, not any date-and-time-stamps on commits; the date-and-time-stamps are irrelevant to the graph structure.¹

I have check the git config --list and it has rebase.autosquash=true

That affects git rebase: it makes a plain git rebase -i act as though you ran git rebase --autosquash -i. See the git config documentation and search for rebase.autoSquash.

To make git pull act as if you had run git pull --rebase, there are multiple configuration options:

• branch.name.rebase can be set to anything that evaluates to boolean true;
• pull.rebase can be set to anything that evaluates to boolean true.

In addition, setting branch.autoSetupRebase directs branch-name-creating operations to set branch.name.rebase to true. Again, see the configuration documentation for details, as this is highly configurable.

---

¹For instance, we can have a series of commits C-D-E where the date and time stamp of commit C is in the 1970s, before Git even existed; the date and time stamp of commit D is set far in the future; and the date and time stamp of commit E is "right now". This is not normal and strongly suggests that the date-stamps were faked. But since Git does not depend on them,² it's harmless.

²Some features in Git speed up use of the commit graph by making assumptions about increasing date stamps. To make this work correctly, some recent Git work now computes a "corrected commit timestamp" internally. For an ordinary commit, the corrected commit timestamp of child C of parent P is max(C.date, P.date+1), more or less. For a root commit we simply use the date stamp as-is and for a multi-parent commit we find max(P.date ? P ∈ parents) and add 1 and use that as the other input to our outer max function.