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

From: Brian Gernhardt <benji@silverinsanity.com>
Date: Jul 7, 2008, 15:03 UTC
Message-ID: <F0AD23BC-FA9A-4593-8942-228C428B661E@silverinsanity.com>
In-Reply-To: <m34p71gbuk.fsf@localhost.localdomain>

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