Brian Gernhardt <benji@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
> ---
>
> 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.
--
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
