threads / patch / 14316

patchMake rebase save ORIG_HEAD if changing current branch

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

## tl;dr

28 messages between Jul 6, 2008 and Jul 8, 2008. Diffs are folded; open one to read it.

replies: 27people: 8as markdown or json

Brian Gernhardt· Jul 6, 2008, 21:22 UTC · lore

This makes rebase act a little more like merge when working on the current branch. This is particularly useful for `git pull --rebase`

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---

 ARG!  This is what v3 was supposed to be.  I should make sure I am sending in
 the correct patch.  (Tip: run format-patch again after a commit --amend.)  Bad
 weekend for me, apparently trying to do too many things at once.  Sorry for
 all the noise.

 To recap:

 If I followed the discussion correctly the first time I sent in this patch,
 the two issues were:

 - Ugly "echo > ORIG_HEAD" instead of pretty "git update-ref ORIG_HEAD"
 - Setting ORIG_HEAD at the wrong place

 This version (as opposed to v2, or the embarrassingly identital "v3")  uses
 the correct variable.  $orig_head looks like the right name, but it stores the
 branch.  $prev_head stores the actual SHA1, which is what I was looking for.

 git-rebase.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Show changes to git-rebase.sh +1 −0

diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..1048f7e 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -434,3 +434,4 @@ do
 done
 
 finish_rb_merge
+git update-ref ORIG_HEAD $prev_head

-- 
1.5.6.2.348.gcff8f.dirty

Junio C Hamano· Jul 7, 2008, 04:43 UTC · re: Brian Gernhardt · lore

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

Brian Gernhardt <benji@silverinsanity.com> writes:

Show 8 quoted lines

> This makes rebase act a little more like merge when working on the
> current branch.  This is particularly useful for `git pull --rebase`
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
>
>  ARG!  This is what v3 was supposed to be.  I should make sure I am sending in
>  the correct patch.

Yeah, I was scratching my head about the discrepancy between the revision comment and the patch in the previous one.

Having said that, thanks to updates to git-rebase, rebased_branch@{1} has useful information these days, so I do not see much practical upside, even though I _will_ apply this patch, just for the sake of consistency.

We would make it _appear_ rebase and merge are interchangeable even more. But the thing is, I am not convinced if promoting that appearance is necessarily a good thing.

You now do not have to say something like:

	After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
	what are new, but 'git pull --rebase' is different and you would
	say 'git diff branch@{1}.." instead.

and you can tell the users that ORIG_HEAD can be used in both cases.

But you cannot say the same thing with "gitk ORIG_HEAD..", for example. The meaning of the topology and commits you would see would be quite different. For rebase you will see your own commits that are carried forward, and for merge you won't. Besides this example, there probably are many fundamental differences between rebase and merge, and trying to give a false impression that they are interchangeable may not add much value to the end user experience, and it could even be harmful from educational point of view.

Brian Gernhardt· Jul 7, 2008, 05:16 UTC · re: Junio C Hamano · lore

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

On Jul 7, 2008, at 12:43 AM, Junio C Hamano wrote:

Show 5 quoted lines

> Having said that, thanks to updates to git-rebase,  
> rebased_branch@{1} has
> useful information these days, so I do not see much practical  
> upside, even
> though I _will_ apply this patch, just for the sake of consistency.

I've been running rebase a lot over the last few days, and my impression was that git-rebase adds an entry to ther eflog for each patch it runs over. While this has its uses, it makes HEAD@{1} not terribly useful after a "pull --rebase". Of course, it took me three tries to get a one-line patch out this weekend, so my judgement is obviously not that great at the moment.

I do appreciate that you'll apply it though. As useful as I find rebasing pull useful, I dislike maintaining patches on top of git. It tends to lead to something breaking when I don't have time to fix it. ;-)

> We would make it _appear_ rebase and merge are interchangeable even  
> more.
> But the thing is, I am not convinced if promoting that appearance is
> necessarily a good thing.

I don't really think promoting it is a good idea, actually. I do, however, think that having ORIG_HEAD set intelligently after a pull is. I nearly added setting ORIG_HEAD to pull, but didn't think that removing it from merge or setting it twice was a good plan.

Besides, I've done the wrong rebase more than once and having the quick recovery is excellent. (Reflogs are great, but when the commit messages are identical it becomes a little difficult to figure out which one to use.)

Show 11 quoted lines

> But you cannot say the same thing with "gitk ORIG_HEAD..", for  
> example.
> The meaning of the topology and commits you would see would be quite
> different.  For rebase you will see your own commits that are carried
> forward, and for merge you won't.  Besides this example, there  
> probably
> are many fundamental differences between rebase and merge, and  
> trying to
> give a false impression that they are interchangeable may not add much
> value to the end user experience, and it could even be harmful from
> educational point of view.

However, the rebased patches may have changed in subtle ways, so having them appear in gitk is a good thing. If I was trying to teach someone git, I'd compare the rebased commits to the merge commit. They both give information on how any conflicts were resolved (although the information is more subtle with rebase).

My final thought is that the rational ORIG_HEAD and when we set it is not clearly documented anywhere. But I am currently out of time to work on git, so that patch won't be coming from me soon.

~~ Brian

Junio C Hamano· Jul 7, 2008, 05:24 UTC · re: Brian Gernhardt · lore

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

Brian Gernhardt <benji@silverinsanity.com> writes:

Show 12 quoted lines

> On Jul 7, 2008, at 12:43 AM, Junio C Hamano wrote:
>
>> Having said that, thanks to updates to git-rebase,
>> rebased_branch@{1} has
>> useful information these days, so I do not see much practical
>> upside, even
>> though I _will_ apply this patch, just for the sake of consistency.
>
> I've been running rebase a lot over the last few days, and my
> impression was that git-rebase adds an entry to ther eflog for each
> patch it runs over.  While this has its uses, it makes HEAD@{1} not
> terribly useful after a "pull --rebase".

Actually, I was not talking about HEAD@{1}. Check the reflog of the branch you rebased, i.e.

	$ git checkout bg/rebase
        $ git rebase master
        $ git diff bg/rebase@{1} bg/rebase

If you have two patches in bg/rebase, HEAD@{2} will be the updated master, HEAD@{1} will be the first patch on top of it, and HEAD will be the rebased tip. bg/rebase@{1} on the other hand is the tip of bg/rebase before you started rebasing (i.e. the result of "git checkout bg/rebase" above).

Junio C Hamano· Jul 7, 2008, 06:28 UTC · re: Brian Gernhardt · lore

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

Brian Gernhardt <benji@silverinsanity.com> writes:

> My final thought is that the rational ORIG_HEAD and when we set it is
> not clearly documented anywhere.  But I am currently out of time to
> work on git, so that patch won't be coming from me soon.

The idea behind ORIG_HEAD is to have an anchoring point before an operation that moves your HEAD in a drastic way. Think if it as a poor-man's reflog -- in fact it predates reflog.

That is why reset saves away the HEAD before it does its thing, so that you can easily say "Oops, I did not mean it -- reset ORIG_HEAD" to flip back to the previous state. Both a fast-forward merge and a real merge can be undone by resetting back to ORIG_HEAD.

So in that sense:

 (1) ORIG_HEAD is not strictly necessary these days, because we have
     reflogs;

 (2) Even then, it is handy and useful, and we could add ORIG_HEAD to more
     commands such as "git am" and "git rebase".

Junio C Hamano· Jul 7, 2008, 06:48 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:

Show 22 quoted lines

> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> My final thought is that the rational ORIG_HEAD and when we set it is
>> not clearly documented anywhere.  But I am currently out of time to
>> work on git, so that patch won't be coming from me soon.
>
> The idea behind ORIG_HEAD is to have an anchoring point before an
> operation that moves your HEAD in a drastic way.  Think if it as a
> poor-man's reflog -- in fact it predates reflog.
>
> That is why reset saves away the HEAD before it does its thing, so that
> you can easily say "Oops, I did not mean it -- reset ORIG_HEAD" to flip
> back to the previous state.  Both a fast-forward merge and a real merge
> can be undone by resetting back to ORIG_HEAD.
>
> So in that sense:
>
>  (1) ORIG_HEAD is not strictly necessary these days, because we have
>      reflogs;
>
>  (2) Even then, it is handy and useful, and we could add ORIG_HEAD to more
>      commands such as "git am" and "git rebase".

Perhaps something like this for "git am" (only minimally tested).

-- >8 -- am: record ORIG_HEAD so that we can quickly undo a large series

This teaches "git-am" to record the commit before it starts its work in ORIG_HEAD, so that application of a large series can be undone by resetting to it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-am.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Show changes to git-am.sh +1 −0

diff --git a/git-am.sh b/git-am.sh
index 2c517ed..818b4e5 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -242,6 +242,7 @@ else
 	else
 		: >"$dotest/applying"
 	fi
+	git update-ref ORIG_HEAD HEAD
 fi
 
 case "$resolved" in

Theodore Tso· Jul 7, 2008, 11:18 UTC · re: Junio C Hamano · lore

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

On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> The idea behind ORIG_HEAD is to have an anchoring point before an
> operation that moves your HEAD in a drastic way.  Think if it as a
> poor-man's reflog -- in fact it predates reflog.
> 
> That is why reset saves away the HEAD before it does its thing, so that
> you can easily say "Oops, I did not mean it -- reset ORIG_HEAD" to flip
> back to the previous state.  Both a fast-forward merge and a real merge
> can be undone by resetting back to ORIG_HEAD.
> 
> So in that sense:
> 
>  (1) ORIG_HEAD is not strictly necessary these days, because we have
>      reflogs;

True, but (and please correct me if I'm wrong) ORIG_HEAD will always be pointing out HEAD before the user typed pretty much any git porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs, it you have to paw through multiple HEAD@{n} to find the 'n' which corresponds to state before executing the git plumbing command, since multiple git plumbing commands could have updated the HEAD's reflog, right?

One of the things that's been on my 'twoud be nice list is having an option to "git reflog show" which prints the timestamp associated with each reflog entry, since tools like guilt tend to create quite a few reflog entries, and looking at the time stamps is one of the easier ways to disentangle it. For now what I tend to do is expand my terminal window so it's super wide, and then look at the raw .git/logs/HEAD file directly.

						- Ted

Jakub Narebski· Jul 7, 2008, 11:42 UTC · re: Theodore Tso · lore

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

Theodore Tso <tytso@MIT.EDU> writes:

Show 22 quoted lines

> On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:
> > The idea behind ORIG_HEAD is to have an anchoring point before an
> > operation that moves your HEAD in a drastic way.  Think if it as a
> > poor-man's reflog -- in fact it predates reflog.
> > 
> > That is why reset saves away the HEAD before it does its thing, so that
> > you can easily say "Oops, I did not mean it -- reset ORIG_HEAD" to flip
> > back to the previous state.  Both a fast-forward merge and a real merge
> > can be undone by resetting back to ORIG_HEAD.
> > 
> > So in that sense:
> > 
> >  (1) ORIG_HEAD is not strictly necessary these days, because we have
> >      reflogs;
> 
> True, but (and please correct me if I'm wrong) ORIG_HEAD will always
> be pointing out HEAD before the user typed pretty much any git
> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,
> it you have to paw through multiple HEAD@{n} to find the 'n' which
> corresponds to state before executing the git plumbing command, since
> multiple git plumbing commands could have updated the HEAD's reflog,
> right?

You can always use _branch_ reflog, either in the <branch>@{1} form, or in @{1} shortcut form. @{1} should be equovalent to ORIG_HEAD even for rebase.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Brian Gernhardt· Jul 7, 2008, 15:03 UTC · re: Jakub Narebski · lore

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

On Jul 7, 2008, at 7:42 AM, Jakub Narebski wrote:

Show 14 quoted lines

> Theodore Tso <tytso@MIT.EDU> writes:
>
>> True, but (and please correct me if I'm wrong) ORIG_HEAD will always
>> be pointing out HEAD before the user typed pretty much any git
>> porcelein command (which saves HEAD into ORIG_HEAD), but with  
>> reflogs,
>> it you have to paw through multiple HEAD@{n} to find the 'n' which
>> corresponds to state before executing the git plumbing command, since
>> multiple git plumbing commands could have updated the HEAD's reflog,
>> right?
>
> You can always use _branch_ reflog, either in the <branch>@{1} form,
> or in @{1} shortcut form.  @{1} should be equovalent to ORIG_HEAD
> even for rebase.

I personally expected @{1} to be identical to HEAD@{1}. Since omitting a ref usually refers to HEAD, why shouldn't omitting it when referring to the reflogs mean the HEAD log? The definition of @{1} is useful since there's no other easy way to get "current branch's reflog", but I think it's non-obvious. (Since HEAD@{1} is something completely different, I think the only other way to refer to @{1} is $ (git symbolic-ref)@{1}.)

Also, your statement is only true if ORIG_HEAD was on the branch you are currently working. If we want ORIG_HEAD to mean "state of HEAD before last command", then "git rebase upstream topic" from master should leave ORIG_HEAD pointing to master, not topic@{1}. It also is no longer true if you switch branches. Having ORIG_HEAD set to the point before a pull is useful to compare multiple branches to both the old and new position of your updated branch.

If we're going to have ORIG_HEAD set by _any_ command, we should probably come up with some consistent definition of it and set it appropriately. The first place most people encounter ORIG_HEAD is after a pull, where it acts something like a reverse of FETCH_HEAD (old state of local vs. new state of remote). However, pull only sets ORIG_HEAD by way of merge and reset sets ORIG_HEAD as well. So the current definition appears to be "the prior state of the last branch to be drastically changed." By this definition, ORIG_HEAD should be set by am and rebase as per Junio's patch.

You could make an argument for removing ORIG_HEAD, it's functionality being replaced by the reflogs. At this point, it's a rather established bit of git, and I think has usefulness of it's own.

~~ Brian

Jeff King· Jul 8, 2008, 04:26 UTC · re: Brian Gernhardt · lore

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

On Mon, Jul 07, 2008 at 11:03:46AM -0400, Brian Gernhardt wrote:

Show 6 quoted lines

> I personally expected @{1} to be identical to HEAD@{1}.  Since omitting a 
> ref usually refers to HEAD, why shouldn't omitting it when referring to 
> the reflogs mean the HEAD log?  The definition of @{1} is useful since 
> there's no other easy way to get "current branch's reflog", but I think 
> it's non-obvious.  (Since HEAD@{1} is something completely different, I 
> think the only other way to refer to @{1} is $(git symbolic-ref)@{1}.)

FYI, there was much discussion about this exact point:

  http://thread.gmane.org/gmane.comp.version-control.git/38379

(I don't know that it has that much bearing on the current discussion, but since I went to the trouble of digging it up, I thought you might find it useful).

-Peff

Brian Gernhardt· Jul 8, 2008, 14:32 UTC · re: Jeff King · lore

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

On Jul 8, 2008, at 12:26 AM, Jeff King wrote:

Show 22 quoted lines

> On Mon, Jul 07, 2008 at 11:03:46AM -0400, Brian Gernhardt wrote:
>
>> I personally expected @{1} to be identical to HEAD@{1}.  Since  
>> omitting a
>> ref usually refers to HEAD, why shouldn't omitting it when  
>> referring to
>> the reflogs mean the HEAD log?  The definition of @{1} is useful  
>> since
>> there's no other easy way to get "current branch's reflog", but I  
>> think
>> it's non-obvious.  (Since HEAD@{1} is something completely  
>> different, I
>> think the only other way to refer to @{1} is $(git symbolic- 
>> ref)@{1}.)
>
> FYI, there was much discussion about this exact point:
>
>  http://thread.gmane.org/gmane.comp.version-control.git/38379
>
> (I don't know that it has that much bearing on the current discussion,
> but since I went to the trouble of digging it up, I thought you might
> find it useful).

Oh, it is useful. And, thinking about it, I agree completely. The syntax isn't immediately obvious, but clear and useful. The need to distinguish between HEAD@{} and $branch@{} is apparent after a moment's reflection, and the chosen solution is fairly obvious at that point. I just never took that moment in my day-to-day working with git.

There's even documentation for it that is clear and understandable. If I was a new user to git, I would have read the documentation and found it. Having used git for a while, I don't bother to look things up and instead try to alter git to match my three years of experience. ;-)

That said, I still want clear and consistent semantics for ORIG_HEAD. And since that now (IMNSHO) exists in next, I'm happy.

~~ Brian

Brian Gernhardt· Jul 7, 2008, 14:36 UTC · re: Theodore Tso · lore

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

On Jul 7, 2008, at 7:18 AM, Theodore Tso wrote:

Show 11 quoted lines

> On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:
>> (1) ORIG_HEAD is not strictly necessary these days, because we have
>>     reflogs;
>
> True, but (and please correct me if I'm wrong) ORIG_HEAD will always
> be pointing out HEAD before the user typed pretty much any git
> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,
> it you have to paw through multiple HEAD@{n} to find the 'n' which
> corresponds to state before executing the git plumbing command, since
> multiple git plumbing commands could have updated the HEAD's reflog,
> right?

This is _exactly_ why I wanted `pull --rebase` to set ORIG_HEAD. Reflogs are great in their own way, but having ORIG_HEAD regularly being available for a quick way to set it back or refer to the original state is just too useful.

~~ Brian

Junio C Hamano· Jul 7, 2008, 18:04 UTC · re: Theodore Tso · lore

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

Theodore Tso <tytso@MIT.EDU> writes:

Show 7 quoted lines

> True, but (and please correct me if I'm wrong) ORIG_HEAD will always
> be pointing out HEAD before the user typed pretty much any git
> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,
> it you have to paw through multiple HEAD@{n} to find the 'n' which
> corresponds to state before executing the git plumbing command, since
> multiple git plumbing commands could have updated the HEAD's reflog,
> right?

You can inspect HEAD's reflog for individual steps, or the branch's reflog for the aggregated moves (try rebasing a few patches on 'test' branch and inspect "git log -g HEAD" and "git log -g test").

> One of the things that's been on my 'twoud be nice list is having an
> option to "git reflog show" which prints the timestamp associated with
> each reflog entry,

	$ git log -g HEAD@{now}
        $ git log -g test@{now}

Please don't complain that interface to specify timestamp output is dirty to me -- I share the same feeling, and it was not my invention. But at least it works ;-)

Junio C Hamano· Jul 7, 2008, 21:58 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> The idea behind ORIG_HEAD is to have an anchoring point before an
> operation that moves your HEAD in a drastic way.  Think if it as a
> poor-man's reflog -- in fact it predates reflog.
>
> That is why reset saves away the HEAD before it does its thing, so that
> you can easily say "Oops, I did not mean it -- reset ORIG_HEAD" to flip
> back to the previous state.  Both a fast-forward merge and a real merge
> can be undone by resetting back to ORIG_HEAD.

I've also seen people complain (quite rightfully) that these FOO_HEAD pseudo refs are not documented in a central place.

How about doing this? It should make it clear what ORIG_HEAD is meant to record, while describing others.

And to answer your "git rebase --onto this from that-branch" question, I think ORIG_HEAD should record the tip of that-branch before rebase takes place, not the commit you happened to be at before running it. Switching branch to that-branch is not the drastic and unforseeable part. The drastic and unforseeable change is rebasing and seeing that the rebased result does not work with the new upstream `from`, and the user would want to have a way to quickly rewind the tip of the branch back to the state before the rebase. The new paragraph added by this patch should hopefully make this reasoning more clear.

-- >8 --
Documentation: update sections on naming revisions and revision ranges

Various *_HEAD pseudo refs were not documented in any central place. Especially since we may be teaching rebase and am to record ORIG_HEAD, it would be a good time to do so.

While at it, reword the explanation on r1..r2 notation to reduce confusion.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 Documentation/git-rev-parse.txt |   20 +++++++++++++++-----
 1 files changed, 15 insertions(+), 5 deletions(-)

Show changes to Documentation/git-rev-parse.txt +15 −5

diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 378a312..7184274 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -166,7 +166,7 @@ blobs contained in a commit.
   first match in the following rules:
 
   . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
-    useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);
+    useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`);
 
   . otherwise, `$GIT_DIR/refs/<name>` if exists;
 
@@ -177,6 +177,16 @@ blobs contained in a commit.
   . otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;
 
   . otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists.
++
+HEAD names the commit your changes in the working tree is based on.
+FETCH_HEAD records the branch you fetched from a remote repository
+with your last 'git-fetch' invocation.
+ORIG_HEAD is created by commands that moves your HEAD in a drastic
+way, to record the position of the HEAD before their operation, so that
+you can change the tip of the branch back to the state before you ran
+them easily.
+MERGE_HEAD records the commit(s) you are merging into your branch
+when you run 'git-merge'.
 
 * A ref followed by the suffix '@' with a date specification
   enclosed in a brace
@@ -289,10 +299,10 @@ notation is used.  E.g. "`{caret}r1 r2`" means commits reachable
 from `r2` but exclude the ones reachable from `r1`.
 
 This set operation appears so often that there is a shorthand
-for it.  "`r1..r2`" is equivalent to "`{caret}r1 r2`".  It is
-the difference of two sets (subtract the set of commits
-reachable from `r1` from the set of commits reachable from
-`r2`).
+for it.  When you have two commits `r1` and `r2` (named according
+to the syntax explained in SPECIFYING REVISIONS above), you can ask
+for commits that are reachable from r2 but not from r1 by
+"`{caret}r1 r2`" and it can be written as "`r1..r2`".
 
 A similar notation "`r1\...r2`" is called symmetric difference
 of `r1` and `r2` and is defined as

Jakub Narebski· Jul 7, 2008, 22:14 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:

> -- >8 --
> Documentation: update sections on naming revisions and revision ranges

[...]

> While at it, reword the explanation on r1..r2 notation to reduce
> confusion.

> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index 378a312..7184274 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt

Show 12 quoted lines

> @@ -289,10 +299,10 @@ notation is used.  E.g. "`{caret}r1 r2`" means commits reachable
>  from `r2` but exclude the ones reachable from `r1`.
>  
>  This set operation appears so often that there is a shorthand
> -for it.  "`r1..r2`" is equivalent to "`{caret}r1 r2`".  It is
> -the difference of two sets (subtract the set of commits
> -reachable from `r1` from the set of commits reachable from
> -`r2`).
> +for it.  When you have two commits `r1` and `r2` (named according
> +to the syntax explained in SPECIFYING REVISIONS above), you can ask
> +for commits that are reachable from r2 but not from r1 by
> +"`{caret}r1 r2`" and it can be written as "`r1..r2`".

I'm not sure if the last part is improvement, and it wouldn't be better to say rather than r1..r2 / ^r1 r2 are "commits that are reachable from r2, excluding those commits which are reachable from r1" (which translates into set difference / subtracting set of commits.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Junio C Hamano· Jul 7, 2008, 22:33 UTC · re: Jakub Narebski · lore

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

Jakub Narebski <jnareb@gmail.com> writes:

Show 17 quoted lines

>> @@ -289,10 +299,10 @@ notation is used.  E.g. "`{caret}r1 r2`" means commits reachable
>>  from `r2` but exclude the ones reachable from `r1`.
>>  
>>  This set operation appears so often that there is a shorthand
>> -for it.  "`r1..r2`" is equivalent to "`{caret}r1 r2`".  It is
>> -the difference of two sets (subtract the set of commits
>> -reachable from `r1` from the set of commits reachable from
>> -`r2`).
>> +for it.  When you have two commits `r1` and `r2` (named according
>> +to the syntax explained in SPECIFYING REVISIONS above), you can ask
>> +for commits that are reachable from r2 but not from r1 by
>> +"`{caret}r1 r2`" and it can be written as "`r1..r2`".
>
> I'm not sure if the last part is improvement, and it wouldn't be better
> to say rather than r1..r2 / ^r1 r2 are "commits that are reachable from
> r2, excluding those commits which are reachable from r1" (which translates
> into set difference / subtracting set of commits.

I tried to make it easier to understand by people without having to know what a set difference is, and that was the reason I did not use "subtract" nor "difference", as I saw somebody was quoting the above part in #git was wondering what it was talking about.

Jakub Narebski· Jul 7, 2008, 22:58 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:

Show 24 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>>> @@ -289,10 +299,10 @@ notation is used.  E.g. "`{caret}r1 r2`" means commits reachable
>>>  from `r2` but exclude the ones reachable from `r1`.
>>>  
>>>  This set operation appears so often that there is a shorthand
>>> -for it.  "`r1..r2`" is equivalent to "`{caret}r1 r2`".  It is
>>> -the difference of two sets (subtract the set of commits
>>> -reachable from `r1` from the set of commits reachable from
>>> -`r2`).
>>> +for it.  When you have two commits `r1` and `r2` (named according
>>> +to the syntax explained in SPECIFYING REVISIONS above), you can ask
>>> +for commits that are reachable from r2 but not from r1 by
>>> +"`{caret}r1 r2`" and it can be written as "`r1..r2`".
>>
>> I'm not sure if the last part is improvement, and it wouldn't be better
>> to say rather than r1..r2 / ^r1 r2 are "commits that are reachable from
>> r2, excluding those commits which are reachable from r1" (which translates
>> into set difference / subtracting set of commits.
> 
> I tried to make it easier to understand by people without having to know
> what a set difference is, and that was the reason I did not use "subtract"
> nor "difference", as I saw somebody was quoting the above part in #git was
> wondering what it was talking about.

I understand, and the replacement you proposed is better, as it does not require understanding of [mathematical] set operations. I just think that "commits that are reachable from r2, excluding those commits which are reachable from r1" could be better than "commits that are reachable from r2 but not from r1".

-- 
Jakub Narebski
Poland

Brian Gernhardt· Jul 8, 2008, 03:24 UTC · re: Junio C Hamano · lore

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

On Jul 7, 2008, at 5:58 PM, Junio C Hamano wrote:

Show 18 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
> And to answer your "git rebase --onto this from that-branch"  
> question, I
> think ORIG_HEAD should record the tip of that-branch before rebase  
> takes
> place, not the commit you happened to be at before running it.   
> Switching
> branch to that-branch is not the drastic and unforseeable part.  The
> drastic and unforseeable change is rebasing and seeing that the  
> rebased
> result does not work with the new upstream `from`, and the user  
> would want
> to have a way to quickly rewind the tip of the branch back to the  
> state
> before the rebase.  The new paragraph added by this patch should  
> hopefully
> make this reasoning more clear.

I just wanted to make sure there was a clear reasoning and to see if someone could word it clearly, as I was getting a little cross-eyed.

Show 6 quoted lines

> -- >8 --
> Documentation: update sections on naming revisions and revision ranges
>
> Various *_HEAD pseudo refs were not documented in any central place.
> Especially since we may be teaching rebase and am to record ORIG_HEAD,
> it would be a good time to do so.

My only objection is to the "may".  ;-)

Also, perhaps we should either list the commands that set ORIG_HEAD, or add a note to that effect in their manpages. I'll see what wording I can come up with, unless you (or someone else) gets to it first of course.

> While at it, reword the explanation on r1..r2 notation to reduce
> confusion.

Looks good.

~~ Brian

Brian Gernhardt· Jul 8, 2008, 04:12 UTC · re: Brian Gernhardt · lore

[PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase

Merge has always set ORIG_HEAD but never mentioned it, while we recently added it to am and rebase. These facts should be reflected in the documentation.

git-reset also sets ORIG_HEAD, but that fact is already mentioned in the very first example so no changes were needed there.

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
 Documentation/git-am.txt     |    6 ++++++
 Documentation/git-merge.txt  |    4 +++-
 Documentation/git-rebase.txt |    3 ++-
 3 files changed, 11 insertions(+), 2 deletions(-)

Show changes to 3 files +11 −2

Documentation/git-am.txt, Documentation/git-merge.txt, Documentation/git-rebase.txt

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 3863eeb..88ca5f1 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -145,6 +145,12 @@ directory exists, so if you decide to start over from scratch,
 run `rm -f -r .dotest` before running the command with mailbox
 names.
 
+Before any patches are applied, ORIG_HEAD is set to the tip of the
+current branch.  This is useful if you have problems with multiple
+commits, like running 'git am' on the wrong branch or an error in the
+commits that is more easily fixed by changing the mailbox (e.g.
+errors in the "From:" lines).
+
 
 SEE ALSO
 --------
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 62f99b5..019e4ca 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -81,7 +81,9 @@ Otherwise, merge will refuse to do any harm to your repository
 (that is, it may fetch the objects from remote, and it may even
 update the local branch used to keep track of the remote branch
 with `git pull remote rbranch:lbranch`, but your working tree,
-`.git/HEAD` pointer and index file are left intact).
+`.git/HEAD` pointer and index file are left intact).  In addition,
+merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
+a problematic merge can be removed by using `git reset ORIG_HEAD`.
 
 You may have local modifications in the working tree files.  In
 other words, 'git-diff' is allowed to report changes.
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index f3459c7..37382c4 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -26,7 +26,8 @@ of commits that would be shown by `git log <upstream>..HEAD`.
 
 The current branch is reset to <upstream>, or <newbase> if the
 --onto option was supplied.  This has the exact same effect as
-`git reset --hard <upstream>` (or <newbase>).
+`git reset --hard <upstream>` (or <newbase>).  This includes setting
+ORIG_HEAD to the pre-rebase tip of the branch.
 
 The commits that were previously saved into the temporary area are
 then reapplied to the current branch, one by one, in order. Note that

-- 
1.5.6.2.393.g45096

Junio C Hamano· Jul 8, 2008, 19:23 UTC · re: Brian Gernhardt · lore

Re: [PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase

Brian Gernhardt <benji@silverinsanity.com> writes:

Show 14 quoted lines

> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index f3459c7..37382c4 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -26,7 +26,8 @@ of commits that would be shown by `git log <upstream>..HEAD`.
>  
>  The current branch is reset to <upstream>, or <newbase> if the
>  --onto option was supplied.  This has the exact same effect as
> -`git reset --hard <upstream>` (or <newbase>).
> +`git reset --hard <upstream>` (or <newbase>).  This includes setting
> +ORIG_HEAD to the pre-rebase tip of the branch.
>  
>  The commits that were previously saved into the temporary area are
>  then reapplied to the current branch, one by one, in order. Note that

I found the above "This includes" part very hard to understand --- it took me three re-reads to connect "This" and "the exact same effect". Is it just me?

I wonder if this is easier to understand:

        The current branch is reset to <upstream>, or <newbase> if the
        --onto option was supplied.  This has the exact same effect as
        `git reset --hard <upstream>` (or <newbase>).  ORIG_HEAD is set
        to point at the tip of the branch before this resetting happens.

Brian Gernhardt· Jul 8, 2008, 19:28 UTC · re: Junio C Hamano · lore

Re: [PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase

On Jul 8, 2008, at 3:23 PM, Junio C Hamano wrote:

Show 24 quoted lines

> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> diff --git a/Documentation/git-rebase.txt b/Documentation/git- 
>> rebase.txt
>> index f3459c7..37382c4 100644
>> --- a/Documentation/git-rebase.txt
>> +++ b/Documentation/git-rebase.txt
>> @@ -26,7 +26,8 @@ of commits that would be shown by `git log  
>> <upstream>..HEAD`.
>>
>> The current branch is reset to <upstream>, or <newbase> if the
>> --onto option was supplied.  This has the exact same effect as
>> -`git reset --hard <upstream>` (or <newbase>).
>> +`git reset --hard <upstream>` (or <newbase>).  This includes setting
>> +ORIG_HEAD to the pre-rebase tip of the branch.
>>
>> The commits that were previously saved into the temporary area are
>> then reapplied to the current branch, one by one, in order. Note that
>
> I found the above "This includes" part very hard to understand ---  
> it took
> me three re-reads to connect "This" and "the exact same effect".  Is  
> it
> just me?

I thought it perfectly easy to understand. ;-) But of course, I wrote it. I also wrote it immediately after reading the git-reset manual, which is why I phrased it that way. On a fresh read, it's less obvious.

Show 7 quoted lines

> I wonder if this is easier to understand:
>
>        The current branch is reset to <upstream>, or <newbase> if the
>        --onto option was supplied.  This has the exact same effect as
>        `git reset --hard <upstream>` (or <newbase>).  ORIG_HEAD is set
>        to point at the tip of the branch before this resetting  
> happens.

I might say "before the reset" instead of "before this resetting happens", as I find the latter slightly awkward. But that's a minor nit

~~ Brian

Jay Soffian· Jul 8, 2008, 03:28 UTC · re: Junio C Hamano · lore

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

On Mon, Jul 7, 2008 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote:

> +HEAD names the commit your changes in the working tree is based on.

How about:

"HEAD names the commit your working tree is based on. This is the tip of the checked out branch, unless HEAD is detached. (HEAD is said to be detached if a commit is checked out which is not the tip of any branch.)"

> +FETCH_HEAD records the branch you fetched from a remote repository
> +with your last 'git-fetch' invocation.

consistency w/above: s/records/names/

> +ORIG_HEAD is created by commands that moves your HEAD in a drastic
> +way, to record the position of the HEAD before their operation, so that
> +you can change the tip of the branch back to the state before you ran
> +them easily.

s/moves/move/; s/can change/can easily change/; s/them easily./them./;

But maybe this reads better:

ORIG_HEAD is created by commands that move HEAD in a drastic way to record the position of HEAD before their operation, so that the branch can easily be reset back to its prior state.

> +MERGE_HEAD records the commit(s) you are merging into your branch
> +when you run 'git-merge'.

So it's the "<remote>" arg or args mentioned in the git-merge man page?

j.

Mike Hommey· Jul 7, 2008, 05:41 UTC · re: Junio C Hamano · lore

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

On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:

Show 29 quoted lines

> Brian Gernhardt <benji@silverinsanity.com> writes:
> 
> > This makes rebase act a little more like merge when working on the
> > current branch.  This is particularly useful for `git pull --rebase`
> >
> > Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> > ---
> >
> >  ARG!  This is what v3 was supposed to be.  I should make sure I am sending in
> >  the correct patch.
> 
> Yeah, I was scratching my head about the discrepancy between the revision
> comment and the patch in the previous one.
> 
> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
> useful information these days, so I do not see much practical upside, even
> though I _will_ apply this patch, just for the sake of consistency.
> 
> We would make it _appear_ rebase and merge are interchangeable even more.
> But the thing is, I am not convinced if promoting that appearance is
> necessarily a good thing.
> 
> You now do not have to say something like:
> 
> 	After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
> 	what are new, but 'git pull --rebase' is different and you would
> 	say 'git diff branch@{1}.." instead.
> 
> and you can tell the users that ORIG_HEAD can be used in both cases.

And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.

Mike

Junio C Hamano· Jul 7, 2008, 05:46 UTC · re: Mike Hommey · lore

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

Mike Hommey <mh@glandium.org> writes:

Show 15 quoted lines

> On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:
> ...
>> We would make it _appear_ rebase and merge are interchangeable even more.
>> But the thing is, I am not convinced if promoting that appearance is
>> necessarily a good thing.
>> 
>> You now do not have to say something like:
>> 
>> 	After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
>> 	what are new, but 'git pull --rebase' is different and you would
>> 	say 'git diff branch@{1}.." instead.
>> 
>> and you can tell the users that ORIG_HEAD can be used in both cases.
>
> And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.

No you cannot.  Read what I wrote again.  I never said HEAD@{1} ;-)

Mike Hommey· Jul 7, 2008, 05:48 UTC · re: Mike Hommey · lore

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

On Mon, Jul 07, 2008 at 07:41:05AM +0200, Mike Hommey wrote:

Show 32 quoted lines

> On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:
> > Brian Gernhardt <benji@silverinsanity.com> writes:
> > 
> > > This makes rebase act a little more like merge when working on the
> > > current branch.  This is particularly useful for `git pull --rebase`
> > >
> > > Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> > > ---
> > >
> > >  ARG!  This is what v3 was supposed to be.  I should make sure I am sending in
> > >  the correct patch.
> > 
> > Yeah, I was scratching my head about the discrepancy between the revision
> > comment and the patch in the previous one.
> > 
> > Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
> > useful information these days, so I do not see much practical upside, even
> > though I _will_ apply this patch, just for the sake of consistency.
> > 
> > We would make it _appear_ rebase and merge are interchangeable even more.
> > But the thing is, I am not convinced if promoting that appearance is
> > necessarily a good thing.
> > 
> > You now do not have to say something like:
> > 
> > 	After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
> > 	what are new, but 'git pull --rebase' is different and you would
> > 	say 'git diff branch@{1}.." instead.
> > 
> > and you can tell the users that ORIG_HEAD can be used in both cases.
> 
> And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.

Forget it, I just woke up, I'm writing crap.

Mike

Nanako Shiraishi· Jul 7, 2008, 06:14 UTC · re: Junio C Hamano · lore

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

Quoting Junio C Hamano <gitster@pobox.com>:

Show 17 quoted lines

> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> This makes rebase act a little more like merge when working on the
>> current branch.  This is particularly useful for `git pull --rebase`
>>
>> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
>> ---
>>
>>  ARG!  This is what v3 was supposed to be.  I should make sure I am sending in
>>  the correct patch.
>
> Yeah, I was scratching my head about the discrepancy between the revision
> comment and the patch in the previous one.
>
> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
> useful information these days, so I do not see much practical upside, even
> though I _will_ apply this patch, just for the sake of consistency.

Are you really aiming for consistency, Junio?

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

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Junio C Hamano· Jul 7, 2008, 07:16 UTC · re: Nanako Shiraishi · lore

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

Nanako Shiraishi <nanako3@lavabit.com> writes:

Show 10 quoted lines

> Quoting Junio C Hamano <gitster@pobox.com>:
> ...
>> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
>> useful information these days, so I do not see much practical upside, even
>> though I _will_ apply this patch, just for the sake of consistency.
>
> Are you really aiming for consistency, Junio?
>
> 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.

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.

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).

-- >8 -- Teach "am" and "rebase" to mark the original position with ORIG_HEAD

"merge" and "reset" leave the original point in history in ORIG_HEAD, which makes it easy to go back to where you were before you inflict a major damage to your history and realize that you do not like the result at all. These days with reflog, we technically do not need to use ORIG_HEAD, but it is a handy way nevertheless.

This teaches "am" and "rebase" (all forms --- the vanilla one that uses "am" as its backend, "-m" variant that cherry-picks, and "--interactive") to do the same.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-am.sh                  |    1 +
 git-rebase--interactive.sh |    1 +
 git-rebase.sh              |    2 +-
 3 files changed, 3 insertions(+), 1 deletions(-)

Show changes to 3 files +3 −1

git-am.sh, git-rebase--interactive.sh, git-rebase.sh

diff --git a/git-am.sh b/git-am.sh
index 2c517ed..fe53608 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -241,6 +241,7 @@ else
 		: >"$dotest/rebasing"
 	else
 		: >"$dotest/applying"
+		git update-ref ORIG_HEAD HEAD
 	fi
 fi
 
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a64d9d5..02d7e3c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -549,6 +549,7 @@ EOF
 		has_action "$TODO" ||
 			die_abort "Nothing to do"
 
+		git update-ref ORIG_HEAD $HEAD
 		output git checkout $ONTO && do_rest
 		;;
 	esac
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..2597d77 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -378,7 +378,7 @@ fi
 echo "First, rewinding head to replay your work on top of it..."
 git checkout "$onto^0" >/dev/null 2>&1 ||
 	die "could not detach HEAD"
-# git reset --hard "$onto^0"
+git update-ref ORIG_HEAD $branch
 
 # If the $onto is a proper descendant of the tip of the branch, then
 # we just fast forwarded.

Brian Gernhardt· Jul 7, 2008, 14:36 UTC · re: Junio C Hamano · lore

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:

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