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

Brian Gernhardt [off-list ref] 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".

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?

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

Theodore Tso [off-list ref] writes:

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

quoted

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

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

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

quoted

(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

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

Theodore Tso [off-list ref] writes:

quoted

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

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

-Peff

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

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

quoted

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