Re: Re* [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch

On Jul 7, 2008, at 3:16 AM, Junio C Hamano wrote:

Nanako Shiraishi [off-list ref] writes:

quoted

Doesn't this make the behavior of the command inconsistent between
"git-rebase" and "git-rebase -m"?

Hmm, it makes "rebase -i" different, too.  Luckily, I haven't pushed
anything out, so I can rewind and all I lose is just a few dozens of
minutes.

Ah, I missed the exit in the $do_merge conditional.  Bah.  I had  
considered rebase--interactive a completely different beast and didn't  
consider it at all.  We've moved a little beyond my goal of "always  
get git-pull to set ORIG_HEAD."  However, consistency is a higher  
goal.  :-)

I originally only set ORIG_HEAD if rebase was operating on the current  
HEAD.  Now we're setting it to the original state of the branch rebase  
is operating on.  Thinking about it, I'm not certain this is what we  
want.  Should ORIG_HEAD refer the the previous state of HEAD, or to  
the previous state of the current branch?

The one from Brian has another serious issue.  That patch does not  
allow
you to refer to ORIG_HEAD during conflict resolution, which is quite
different from how "merge" lets you use ORIG_HEAD.  We need to set
ORIG_HEAD upfront if we want to tell user that ORIG_HEAD can be  
reliably
used across workflows the same way to name where we were before.

I was under the impression that this was not desired.  I originally  
get ORIG_HEAD up front, and was told that it should happen much later  
in the process so that a reset during conflict resolution wouldn't  
blow it away.

When we correctly update "rebase" to do this, because one codepath  
of it
uses "am" as its backend, we cannot use the patch I sent out  
earlier.  We
probably need to do something like this (minimally tested).

The patch looks correct to me, other than my question of what  
ORIG_HEAD should be set to after "git rebase upstream other_branch".

~~ Brian