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

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

[Brian Gernhardt]

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

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

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

[Junio C Hamano]

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.

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.

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

[Brian Gernhardt]

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

> 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

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

[Junio C Hamano]

Brian Gernhardt <benji@silverinsanity.com> writes:

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

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

[Mike Hommey]

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.

Mike

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

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> 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} ;-)

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

[Mike Hommey]

On Mon, Jul 07, 2008 at 07:41:05AM +0200, Mike Hommey wrote:
> 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

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

[Nanako Shiraishi]

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

> 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/

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

[Junio C Hamano]

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

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

[Junio C Hamano]

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

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

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

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

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

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.

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

[Theodore Tso]

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

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

[Jakub Narebski]

Theodore Tso <tytso@MIT.EDU> writes:

> 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

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

[Brian Gernhardt]

On Jul 7, 2008, at 3:16 AM, Junio C Hamano wrote:

> 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?

> 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

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

[Brian Gernhardt]

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:
>> (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

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

[Brian Gernhardt]

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

> 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

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

[Junio C Hamano]

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

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

[Junio C Hamano]

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

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

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

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

[Jakub Narebski]

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

> @@ -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

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

[Junio C Hamano]

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.

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

[Jakub Narebski]

Junio C Hamano wrote:
> 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

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

[Brian Gernhardt]

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

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

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

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

[Jay Soffian]

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.

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

[Brian Gernhardt]

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

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

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

[Jeff King]

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

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

[Brian Gernhardt]

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

> 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

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

[Junio C Hamano]

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

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

[Brian Gernhardt]

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

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

> 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