git pull --rebase differs in behavior from git fetch + git rebase

git pull --rebase differs in behavior from git fetch + git rebase

[Joshua Jensen]

  I have a case where 'git pull --rebase' does not do the Right Thing 
(according to me).

If I run 'git rebase origin/master', that rebase does the right thing, 
perfectly reapplying my *single* commit on top of the upstream.

'git pull --rebase' ends up reapplying a bunch of much earlier commits 
and ends up with a conflict.

The documentation for git pull --rebase states: "Instead of a merge, 
perform a rebase after fetching. If there is a remote ref for the 
upstream branch, and this branch was rebased since last fetched, the 
rebase uses that information to avoid rebasing non-local changes."  I do 
not understand

I'm studying the git-pull script right now, but I have to admit this is 
beyond me.  I'm sure if I stare hard enough, I'll get it.

I mistakenly have assumed 'git pull' = 'git fetch; git merge' and that 
'git pull --rebase' = 'git fetch; git rebase'.  Does anyone want to 
clarify what is really going on?  Unfortunately, I can't publish the 
repository in question.

Thanks!

Josh

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Santi Béjar]

Can you try the latest master branch of git.git?

Santi

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Dave Olszewski]

On Thu, 26 Aug 2010, Joshua Jensen wrote:

> I have a case where 'git pull --rebase' does not do the Right Thing 
> (according to me).
>
> If I run 'git rebase origin/master', that rebase does the right thing, 
> perfectly reapplying my *single* commit on top of the upstream.
>
> 'git pull --rebase' ends up reapplying a bunch of much earlier commits and 
> ends up with a conflict.
>
> The documentation for git pull --rebase states: "Instead of a merge, perform 
> a rebase after fetching. If there is a remote ref for the upstream branch, 
> and this branch was rebased since last fetched, the rebase uses that 
> information to avoid rebasing non-local changes."  I do not understand
>
> I'm studying the git-pull script right now, but I have to admit this is 
> beyond me.  I'm sure if I stare hard enough, I'll get it.
>
> I mistakenly have assumed 'git pull' = 'git fetch; git merge' and that 'git 
> pull --rebase' = 'git fetch; git rebase'.  Does anyone want to clarify what 
> is really going on?  Unfortunately, I can't publish the repository in 
> question.

Are you by any chance running a git with commit cf65426de?  If not, give
it a try and see if it corrects your issue.

The main difference between "git pull --rebase" and "git fetch && git
rebase @{u}" is that "git pull --rebase" will attempt to use the reflog
to find a suitable "upstream" candidate instead of assuming your
tracking branch is the upstream itself.  This is intended to help
recover from upstream rebases, but has adverse effects sometimes, which
commit cf65426de should help with.

     Dave

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Joshua Jensen]

  ----- Original Message -----
From: Dave Olszewski
Date: 8/27/2010 2:27 AM
> On Thu, 26 Aug 2010, Joshua Jensen wrote:
>
>> I have a case where 'git pull --rebase' does not do the Right Thing 
>> (according to me).
>>
>> If I run 'git rebase origin/master', that rebase does the right 
>> thing, perfectly reapplying my *single* commit on top of the upstream.
>>
>> 'git pull --rebase' ends up reapplying a bunch of much earlier 
>> commits and ends up with a conflict.
>>
>> The documentation for git pull --rebase states: "Instead of a merge, 
>> perform a rebase after fetching. If there is a remote ref for the 
>> upstream branch, and this branch was rebased since last fetched, the 
>> rebase uses that information to avoid rebasing non-local changes."  I 
>> do not understand
>>
>> I'm studying the git-pull script right now, but I have to admit this 
>> is beyond me.  I'm sure if I stare hard enough, I'll get it.
>>
>> I mistakenly have assumed 'git pull' = 'git fetch; git merge' and 
>> that 'git pull --rebase' = 'git fetch; git rebase'.  Does anyone want 
>> to clarify what is really going on?  Unfortunately, I can't publish 
>> the repository in question.
>
> Are you by any chance running a git with commit cf65426de?  If not, give
> it a try and see if it corrects your issue.
I was not, but now I am.
> The main difference between "git pull --rebase" and "git fetch && git
> rebase @{u}" is that "git pull --rebase" will attempt to use the reflog
> to find a suitable "upstream" candidate instead of assuming your
> tracking branch is the upstream itself.  This is intended to help
> recover from upstream rebases, but has adverse effects sometimes, which
> commit cf65426de should help with.
Unfortunately, commit cf65426de helps only a little.  The 'git pull 
--rebase' reports "Nothing to do" and moves the master branch to 
origin/master, leaving behind the commit needing to be rebased.

What else might there be to try?  I would like to help with a repro, if 
possible.

Josh

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Elijah Newren]

On Fri, Aug 27, 2010 at 9:48 AM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
>> The main difference between "git pull --rebase" and "git fetch && git
>> rebase @{u}" is that "git pull --rebase" will attempt to use the reflog
>> to find a suitable "upstream" candidate instead of assuming your
>> tracking branch is the upstream itself.  This is intended to help
>> recover from upstream rebases, but has adverse effects sometimes, which
>> commit cf65426de should help with.
>
> Unfortunately, commit cf65426de helps only a little.  The 'git pull
> --rebase' reports "Nothing to do" and moves the master branch to
> origin/master, leaving behind the commit needing to be rebased.
>
> What else might there be to try?  I would like to help with a repro, if
> possible.

Try modifying the git-pull script; change the last line from
  eval "exec $eval"
to
  echo "exec $eval"
.

Is the output of the form
  git-rebase --onto XXXX YYYY
or
  git-rebase --onto XXXX XXXX
?

With cf65426de, and from what I'm guessing from your description, I'd
expect the latter.  And, I'd assume the latter is equivalent to
'git-rebase XXXX', but you say that's not the behavior you're getting.
 Finding out which of my assumptions is wrong may help you debug the
issue.

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Joshua Jensen]

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 12:46 PM
> On Fri, Aug 27, 2010 at 9:48 AM, Joshua Jensen
> <jjensen@workspacewhiz.com>  wrote:
>>> The main difference between "git pull --rebase" and "git fetch&&  git
>>> rebase @{u}" is that "git pull --rebase" will attempt to use the reflog
>>> to find a suitable "upstream" candidate instead of assuming your
>>> tracking branch is the upstream itself.  This is intended to help
>>> recover from upstream rebases, but has adverse effects sometimes, which
>>> commit cf65426de should help with.
>> Unfortunately, commit cf65426de helps only a little.  The 'git pull
>> --rebase' reports "Nothing to do" and moves the master branch to
>> origin/master, leaving behind the commit needing to be rebased.
>>
>> What else might there be to try?  I would like to help with a repro, if
>> possible.
> Try modifying the git-pull script; change the last line from
>    eval "exec $eval"
> to
>    echo "exec $eval"
> .
>
> Is the output of the form
>    git-rebase --onto XXXX YYYY
> or
>    git-rebase --onto XXXX XXXX
> ?
>
> With cf65426de, and from what I'm guessing from your description, I'd
> expect the latter.  And, I'd assume the latter is equivalent to
> 'git-rebase XXXX', but you say that's not the behavior you're getting.
>   Finding out which of my assumptions is wrong may help you debug the
> issue.
It reports to me 'git-rebase --onto XXXX XXXX'.

And it reports nothing to do.

XXXX is properly the origin/master in this case.

git rebase origin/master           works.
git rebase --onto origin/master origin/master       does not work.

Thoughts?

Josh

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Elijah Newren]

On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> It reports to me 'git-rebase --onto XXXX XXXX'.
>
> And it reports nothing to do.
>
> XXXX is properly the origin/master in this case.
>
> git rebase origin/master           works.
> git rebase --onto origin/master origin/master       does not work.
>
> Thoughts?

It's too bad you can't make this repository public; I thought rebase
should behave the same for those two commands.  We could certainly
just modify git-pull.sh to avoid using the --onto flag when
oldremoteref is not defined (and perhaps that makes sense independent
of anything else), but I'm curious now about rebase.

Can you insert an echo statement right before where git-rebase calls
format-patch to see what arguments it is passing in those two cases?
For me it's around line 568; insert an echo statement so that it looks
like:
 if test -z "$do_merge"
 then
        echo git format-patch -k --stdout --full-index --ignore-if-in-upstream \
               --no-renames $root_flag "$revisions"
        git format-patch -k --stdout --full-index --ignore-if-in-upstream \
                --no-renames $root_flag "$revisions" |
        git am $git_am_opt --rebasing --resolvemsg="$RESOLVEMSG" &&
Make that change, and then run it with both your rebase commands and
see what you get.

For me, in both cases, I get:
  git format-patch ... --no-renames origin/master..HEAD
(except sha1sums of what origin/master and HEAD were rather than that
literal text), which means the same patches are being applied in both
cases for me.

Elijah

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Joshua Jensen]

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 5:40 PM
> On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen
> <jjensen@workspacewhiz.com>  wrote:
>> It reports to me 'git-rebase --onto XXXX XXXX'.
>>
>> And it reports nothing to do.
>>
>> XXXX is properly the origin/master in this case.
>>
>> git rebase origin/master           works.
>> git rebase --onto origin/master origin/master       does not work.
>>
>> Thoughts?
> It's too bad you can't make this repository public; I thought rebase
> should behave the same for those two commands.  We could certainly
> just modify git-pull.sh to avoid using the --onto flag when
> oldremoteref is not defined (and perhaps that makes sense independent
> of anything else), but I'm curious now about rebase.
>
> Can you insert an echo statement right before where git-rebase calls
> format-patch to see what arguments it is passing in those two cases?
> For me it's around line 568; insert an echo statement so that it looks
> like:
>   if test -z "$do_merge"
>   then
>          echo git format-patch -k --stdout --full-index --ignore-if-in-upstream \
>                 --no-renames $root_flag "$revisions"
>          git format-patch -k --stdout --full-index --ignore-if-in-upstream \
>                  --no-renames $root_flag "$revisions" |
>          git am $git_am_opt --rebasing --resolvemsg="$RESOLVEMSG"&&
> Make that change, and then run it with both your rebase commands and
> see what you get.
>
> For me, in both cases, I get:
>    git format-patch ... --no-renames origin/master..HEAD
> (except sha1sums of what origin/master and HEAD were rather than that
> literal text), which means the same patches are being applied in both
> cases for me.
Okay, there is _not_ a problem with the patch in 1.7.2.2 for the 
"broken" repository I have in front of me right now, but I wish I hadn't 
trashed the other broken repository someone else had.  :(

Before running a successful 'git rebase origin/master' on the broken 
repository, I made a copy of it.  That person then committed and pushed 
the rebased commit.  _I did not know that._

I copied the broken repository into two locations, testrebase and 
testpullrebase.

In the testrebase repository, I ran 'git rebase origin/master'.  I did 
not fetch, so the repository was in the same state as the original 
broken copy.

In the testpullrebase repository, I ran 'git pull --rebase'.  It fetched 
the latest commits (which included the person's pushed rebase commit), 
and I saw it supposedly didn't rebase the commit.  However, it did the 
RIGHT thing, because the commit already exists in the repository.

Sorry for causing an issue, but I definitely appreciate the fix already 
being available.

Josh

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Elijah Newren]

On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> Okay, there is _not_ a problem with the patch in 1.7.2.2 for the "broken"
> repository I have in front of me right now, but I wish I hadn't trashed the
> other broken repository someone else had.  :(
>

> Sorry for causing an issue, but I definitely appreciate the fix already
> being available.

Not a problem; it's totally understandable.  Believe me, I had a whole
bunch of similar problems when trying to deal with this bug when
people were hitting it at work (e.g. trying to duplicate by cloning,
which never worked since the bug depended on reflog state).

In any event, I'm glad it's working for you now.  :-)

Elijah

Re: git pull --rebase differs in behavior from git fetch + git rebase

[Joshua Jensen]

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 8:40 PM
> On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen
> <jjensen@workspacewhiz.com>  wrote:
>> Okay, there is _not_ a problem with the patch in 1.7.2.2 for the "broken"
>> repository I have in front of me right now, but I wish I hadn't trashed the
>> other broken repository someone else had.  :(
As it turns out, the other broken repository exists still, but it will 
be Monday before I can test against the 1.7.2.2 change.
>> Sorry for causing an issue, but I definitely appreciate the fix already
>> being available.
> Not a problem; it's totally understandable.  Believe me, I had a whole
> bunch of similar problems when trying to deal with this bug when
> people were hitting it at work (e.g. trying to duplicate by cloning,
> which never worked since the bug depended on reflog state).
Fortunately, I've worked with Git long enough now that I knew to direct 
copy the .git folder to the new location, 'git reset --hard' to get the 
files back, and hopefully then be in the same state.
> In any event, I'm glad it's working for you now.  :-)
Me, too.

Now, if only 'git rebase --preserve-merges' would work all the time and 
could be the default.  (I have instances where a topic branch is merged 
back to master with --no-ff to generate the merge commit, an attempt is 
made to push but new commits have been added from others, so a pull 
--rebase is performed and ends up replaying the merge linearly... no 
merge commit... oh, well.)

Take care.

Josh