git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Brian Gernhardt <benji@silverinsanity.com>
Date
Jul 7, 2008, 14:36 UTC
Message-ID
<33AA0978-99F2-4BF0-840B-BB4781A23217@silverinsanity.com>
In-Reply-To
<7vvdzi5fl5.fsf@gitster.siamese.dyndns.org>
On Jul 7, 2008, at 3:16 AM, Junio C Hamano wrote:
Show 8 quoted lines
> Nanako Shiraishi <nanako3@lavabit.com> 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?

Show 7 quoted lines
> 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.

Show 5 quoted lines
> 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
Previous: Junio C Hamano
Message 28 of 28 in “Make rebase save ORIG_HEAD if changing current branch”
  1. Make rebase save ORIG_HEAD if changing current branchBrian Gernhardt, Jul 6, 2008
  2. Junio C HamanoJul 7, 2008
  3. Brian GernhardtJul 7, 2008
  4. Junio C HamanoJul 7, 2008
  5. Junio C HamanoJul 7, 2008
  6. Junio C HamanoJul 7, 2008
  7. Theodore TsoJul 7, 2008
  8. Jakub NarebskiJul 7, 2008
  9. Brian GernhardtJul 7, 2008
  10. Jeff KingJul 8, 2008
  11. Brian GernhardtJul 8, 2008
  12. Brian GernhardtJul 7, 2008
  13. Junio C HamanoJul 7, 2008
  14. Junio C HamanoJul 7, 2008
  15. Jakub NarebskiJul 7, 2008
  16. Junio C HamanoJul 7, 2008
  17. Jakub NarebskiJul 7, 2008
  18. Brian GernhardtJul 8, 2008
  19. Documentation: mention ORIG_HEAD in am, merge, and rebaseBrian Gernhardt, Jul 8, 2008
  20. Junio C HamanoJul 8, 2008
  21. Brian GernhardtJul 8, 2008
  22. Jay SoffianJul 8, 2008
  23. Mike HommeyJul 7, 2008
  24. Junio C HamanoJul 7, 2008
  25. Mike HommeyJul 7, 2008
  26. Nanako ShiraishiJul 7, 2008
  27. Re* [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branchJunio C Hamano, Jul 7, 2008
  28. Brian GernhardtJul 7, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.