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

From: Brian Gernhardt <benji@silverinsanity.com>
Date: Jul 7, 2008, 05:16 UTC
Message-ID: <803A3528-2451-4C5D-A48D-5E0C37B8E90E@silverinsanity.com>
In-Reply-To: <7v7iby9ucx.fsf@gitster.siamese.dyndns.org>

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