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.

Forgot to say that I am using version 1.6.5.1.1367.gcd48 (Cygwin). I should also say that I can see no particular reason why exactly two extra commits were picked.

martinvz wrote:

On Thu, Jan 7, 2010 at 1:23 PM, martinvz <martin.von.zweigbergk@gmail.com> wrote:

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

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?

Thanks, Martin

Santi Béjar-2 wrote:

[Do not top post, as it breaks the conversation flow]

On Thu, Jan 7, 2010 at 7:44 PM, martinvz <martin.von.zweigbergk@gmail.com> wrote:

This is used when the upstream branch is rebased, as you only want to rebase the local commits and not commits in the old upstream branch.

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.

Santi

Santi Béjar-2 wrote:

Sorry, but I'm not sure I understand what that means. Most of the commits in the upstream branch (the remote main branch) were rebased onto that branch at some point in time before being pushed to our shared repository. The remote branch itself was never rebased against any other branch (all destructive operations disallowed in Gitosis). I hope that (possibly along with the information below) answers your question.

Santi Béjar-2 wrote:

$ 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/main@{0}: fetch origin: fast forward 3ffe7df refs/remotes/origin/main@{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.

Something else that may or may not have something to do with the problem is that there is also a branch called origin/main-stable (pointing to the same commit as origin/main). I also have a local main branch (also same commit as origin/main). I don't know if any of this could confuse Git. (To be perfectly honest, it is actually the origin/main-stable branch I'm trying to pull from, just in case you think the branch name could have any impact.)

Thanks, Martin

On Fri, Jan 8, 2010 at 12:38 AM, martinvz <martin.von.zweigbergk@gmail.com> wrote:

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?

HTH, Santi

Santi Béjar-2 wrote:

Thanks, Santi! After thinking for a while about what you said, I think I understand. That could definitely be what I did, although I can't remember for sure.

Would it make sense to teach "git rebase" the same tricks as "git pull --rebase"?

Santi Béjar-2 wrote:

Almost - it fails, but the merge tool resolves it automatically.

Martin