Difference between pull --rebase and fetch+rebase

I have a branch configured to track a remote branch by rebasing. I excepted that "git pull" would therefore be equivalent to fetching from the remote repository followed by rebasing the remote branch, but it isn't. When doing "git rebase <remote>/<branch>", it applies only the commits after the merge base. When doing "git pull", it tries to apply two more commits (the two commits preceding the merge base). Why is this?

I get the same result even if I do "git pull --rebase <remote> <branch>", it doesn't seem to have anything to do with incorrect configuration of the branch.

I have a branch configured to track a remote branch by rebasing. I excepted that "git pull" would therefore be equivalent to fetching from the remote repository followed by rebasing the remote branch, but it isn't. When doing "git rebase <remote>/<branch>", it applies only the commits after the merge base. When doing "git pull", it tries to apply two more commits (the two commits preceding the merge base). Why is this?

I get the same result even if I do "git pull --rebase <remote> <branch>", it doesn't seem to have anything to do with incorrect configuration of the branch.

Quoted 11 lines · martinvz

I have a branch configured to track a remote branch by rebasing. I excepted
that "git pull" would therefore be equivalent to fetching from the remote repository followed by rebasing the remote branch, but it isn't. When doing
"git rebase <remote>/<branch>", it applies only the commits after the merge
base. When doing "git pull", it tries to apply two more commits (the two commits preceding the merge base). Why is this?

Quoted 4 lines

I get the same result even if I do "git pull --rebase <remote> <branch>", it
doesn't seem to have anything to do with incorrect configuration of the branch.

Yes, both should do the same (at least when upstream is not rebased). Can you provide a test case or instructions to reproduce the behavior?

Thanks,
Santi
--
To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Thanks for your post, Santi. I can not share my repository since it is a project at work. I was troubleshooting a bit myself and found the following section in git-pull.sh:

       oldremoteref="$(git rev-parse -q --verify "$remoteref")" && for reflog in $(git rev-list -g $remoteref 2>/dev/null) do
               if test "$reflog" = "$(git merge-base $reflog $curr_branch)" then
                       oldremoteref="$reflog"
                       break
               fi
       done

Why is it that reflog entries are allowed to override the remote reference?

Is your upstream branch rebased?

Can you provide, at least, a graph of your history (ala git log --graph --oneline for example)? And plot also the reflog entries and all the important commits.

Quoted 5 lines · Santi Béjar-2 wrote:

Can you provide, at least, a graph of your history (ala git log --graph --oneline for example)? And plot also the reflog entries and all the important commits.

$ git log --graph --format=%h --all
* 2038a46 # topic-2
* a7b93b2
* f2501ae # origin/main
* cd5aaa9
* cb232f3
...
* 5ed0d06
* 3067862
| * 6eba2fa # topic-1
| * b09aaf4
| * bc3b72a
|/
| * 03d0d84 # topic-3
| * 5160773
| * 3c25642
|/
| * 6e9b12b # topic-4
| * 75f5ab2
| * bdd08ce
| * b5d5759
|/
* 486b580
* a021696
* 3ffe7df
* d0f55c5
...

I have topic-1 checked out and run "git pull" and expect it to rebase (only) commits bc3b72a, b09aaf4, 6eba2fa onto f2501ae, but it starts by applying a021696 and 486b580.

$ git reflog -g origin/main
f2501ae refs/remotes/origin/mai  n@{0}: fetch origin: fast forward
3ffe7df refs/remotes/origin/mai  n@{1}: fetch origin: fast forward
...

I hope that's all that's all you need. It seems that the problem is that the oldremoteref gets overwritten with the entry from the reflog. Is the problem that 3ffe7df appears in the reflog or that 486b580 doesn't appear there? I'm not clear on what ends up in the reflog.

I just realized that I myself created a021696 and 486b580 (but not 3ffe7df), probably by rebasing some now-dead branch against origin/main.

Yes, it is. The code expects that you always branch your topic branches from the upstream branch, so all the possible fork points are in the reflog. Your flow was to create the topic from a local commit and then push that commit.

By the way, when Git tries to apply these two commits it should detect that they are already applied so it should do nothing, isn't it?