Re: [PATCHv4 2/2] pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches

[Elijah Newren <newren@gmail.com>]

Hi,

Thanks for the review and comments!

On Thu, Aug 12, 2010 at 7:34 AM, Santi Béjar <santi@agolina.net> wrote:
<snip>
> All this makes sense.
>
> But can you explain when it happens? One possibility is when you don't
> fork from the tracking branch as in:

That's one possibility.  Patch 1/2 in this thread contains testcases
for two others.  Another possibility is having your patches get
upstream by some alternative route (e.g. pulling your changes to a
third machine, pushing from there, and then going back to your
original machine and trying to pull --rebase).

> Subject: Difference between pull --rebase and fetch+rebase
> Message-ID: <27059158.post@talk.nabble.com>
> From: martinvz <martin.von.zweigbergk@gmail.com>
>
> and this patch should also fix martinvz's issue (I've CC martinvz, can
> you test this patch? Thanks).

Since you've cc'd martinvz, I'll note for his benefit that in the
thread you reference above, you stated,

"By the way, when Git tries to apply these two commits it should detect
that they are already applied so it should do nothing, isn't it?"

The answer is no, it won't detect they are already applied, as
explained in the commit message that started the current thread.  (If
git did detect the changes were already applied, this bug would have
been innocuous.)

> Can you refer to commits with something like this?
>
> c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26)

Sure, I'll start doing that.

> You've moved all the lines after the call to "git fetch". It changes
> the behavior when the reflog is not enabled, as the old value of
> remoteref is lost.

Doh.  That's what I get for trying to 'clean up' some code and put all
the references to setting oldremoteref together.  I should have stuck
with my original 7-line addition patch.  I'll resend the simplified
patch.

Elijah