On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen
<jjensen@xxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html