On Jul 7, 2008, at 3:16 AM, Junio C Hamano wrote:
Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes:
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
--
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
