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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2008, 04:43 UTC
Message-ID: <7v7iby9ucx.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1215379370-34265-1-git-send-email-benji@silverinsanity.com>

Brian Gernhardt <benji@silverinsanity.com> writes:

Show 8 quoted lines

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