Difference between pull --rebase and fetch+rebase

Difference between pull --rebase and fetch+rebase

[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?

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.
-- 
View this message in context: http://old.nabble.com/Difference-between-pull---rebase-and-fetch%2Brebase-tp27059158p27059158.html
Sent from the git mailing list archive at Nabble.com.

Re: Difference between pull --rebase and fetch+rebase

[martinvz]

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:
> 
> 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.
> 

-- 
View this message in context: http://old.nabble.com/Difference-between-pull---rebase-and-fetch%2Brebase-tp27059158p27059574.html
Sent from the git mailing list archive at Nabble.com.

Re: Difference between pull --rebase and fetch+rebase

[Santi Béjar]

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

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

Re: Difference between pull --rebase and fetch+rebase

[martinvz]

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:
> 
> On Thu, Jan 7, 2010 at 1:23 PM, martinvz
> <martin.von.zweigbergk@gmail.com> wrote:
>>
>> 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.
> 
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 
View this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4268064.html
Sent from the git mailing list archive at Nabble.com.

Re: Difference between pull --rebase and fetch+rebase

[Santi Béjar]

[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:
>
> 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?

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

Re: Difference between pull --rebase and fetch+rebase

[martinvz]

Santi Béjar-2 wrote:
> 
> Is your upstream branch rebased?
> 

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:
> 
> 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\x7f\x7fn@{0}: fetch origin: fast forward
3ffe7df refs/remotes/origin/mai\x7f\x7fn@{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

-- 
View this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4269422.html
Sent from the git mailing list archive at Nabble.com.

Re: Difference between pull --rebase and fetch+rebase

[Santi Béjar]

On Fri, Jan 8, 2010 at 12:38 AM, martinvz
<martin.von.zweigbergk@gmail.com> wrote:
>
>
> 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?

HTH,
Santi

Re: Difference between pull --rebase and fetch+rebase

[martinvz]

Santi Béjar-2 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.
> 

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:
> 
> 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?
> 

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


Martin
-- 
View this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4274470.html
Sent from the git mailing list archive at Nabble.com.