* git pull --rebase differs in behavior from git fetch + git rebase
@ 2010-08-27 2:59 Joshua Jensen
2010-08-27 7:23 ` Santi Béjar
2010-08-27 8:27 ` Dave Olszewski
0 siblings, 2 replies; 10+ messages in thread
From: Joshua Jensen @ 2010-08-27 2:59 UTC (permalink / raw)
To: git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-27 2:59 git pull --rebase differs in behavior from git fetch + git rebase Joshua Jensen
@ 2010-08-27 7:23 ` Santi Béjar
2010-08-27 8:27 ` Dave Olszewski
1 sibling, 0 replies; 10+ messages in thread
From: Santi Béjar @ 2010-08-27 7:23 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
Can you try the latest master branch of git.git?
Santi
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-27 2:59 git pull --rebase differs in behavior from git fetch + git rebase Joshua Jensen
2010-08-27 7:23 ` Santi Béjar
@ 2010-08-27 8:27 ` Dave Olszewski
2010-08-27 15:48 ` Joshua Jensen
1 sibling, 1 reply; 10+ messages in thread
From: Dave Olszewski @ 2010-08-27 8:27 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-27 8:27 ` Dave Olszewski
@ 2010-08-27 15:48 ` Joshua Jensen
2010-08-27 18:46 ` Elijah Newren
0 siblings, 1 reply; 10+ messages in thread
From: Joshua Jensen @ 2010-08-27 15:48 UTC (permalink / raw)
To: Dave Olszewski; +Cc: git@vger.kernel.org
----- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-27 15:48 ` Joshua Jensen
@ 2010-08-27 18:46 ` Elijah Newren
2010-08-27 22:29 ` Joshua Jensen
0 siblings, 1 reply; 10+ messages in thread
From: Elijah Newren @ 2010-08-27 18:46 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Dave Olszewski, git@vger.kernel.org
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-27 18:46 ` Elijah Newren
@ 2010-08-27 22:29 ` Joshua Jensen
2010-08-27 23:40 ` Elijah Newren
0 siblings, 1 reply; 10+ messages in thread
From: Joshua Jensen @ 2010-08-27 22:29 UTC (permalink / raw)
To: Elijah Newren; +Cc: Dave Olszewski, git@vger.kernel.org
----- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-27 22:29 ` Joshua Jensen
@ 2010-08-27 23:40 ` Elijah Newren
2010-08-28 2:06 ` Joshua Jensen
0 siblings, 1 reply; 10+ messages in thread
From: Elijah Newren @ 2010-08-27 23:40 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Dave Olszewski, git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-27 23:40 ` Elijah Newren
@ 2010-08-28 2:06 ` Joshua Jensen
2010-08-28 2:40 ` Elijah Newren
0 siblings, 1 reply; 10+ messages in thread
From: Joshua Jensen @ 2010-08-28 2:06 UTC (permalink / raw)
To: Elijah Newren; +Cc: Dave Olszewski, git@vger.kernel.org
----- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-28 2:06 ` Joshua Jensen
@ 2010-08-28 2:40 ` Elijah Newren
2010-08-28 3:13 ` Joshua Jensen
0 siblings, 1 reply; 10+ messages in thread
From: Elijah Newren @ 2010-08-28 2:40 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Dave Olszewski, git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git pull --rebase differs in behavior from git fetch + git rebase
2010-08-28 2:40 ` Elijah Newren
@ 2010-08-28 3:13 ` Joshua Jensen
0 siblings, 0 replies; 10+ messages in thread
From: Joshua Jensen @ 2010-08-28 3:13 UTC (permalink / raw)
To: Elijah Newren; +Cc: Dave Olszewski, git@vger.kernel.org
----- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-08-28 3:13 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-27 2:59 git pull --rebase differs in behavior from git fetch + git rebase Joshua Jensen
2010-08-27 7:23 ` Santi Béjar
2010-08-27 8:27 ` Dave Olszewski
2010-08-27 15:48 ` Joshua Jensen
2010-08-27 18:46 ` Elijah Newren
2010-08-27 22:29 ` Joshua Jensen
2010-08-27 23:40 ` Elijah Newren
2010-08-28 2:06 ` Joshua Jensen
2010-08-28 2:40 ` Elijah Newren
2010-08-28 3:13 ` Joshua Jensen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).