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

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