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

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 5:40 PM

On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen
[off-list ref]  wrote:

quoted

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