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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
