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

[Joshua Jensen <jjensen@workspacewhiz.com>]

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