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

From: Elijah Newren <newren@gmail.com>
Date: Aug 27, 2010, 23:40 UTC
Message-ID: <AANLkTimBv3EVWaEnateD95sUi_LkmNw8RKJZYrW4dUFy@mail.gmail.com>
In-Reply-To: <4C783C66.3000008@workspacewhiz.com>

On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen <jjensen@workspacewhiz.com> wrote:

Show 10 quoted lines

> 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