Re: merge vs rebase: Is visualization in gitk the only problem?

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 27, 2007, 08:58 UTC
Message-ID: <CEA39C15-F9AE-46F5-BBE9-3F7AB0711494@zib.de>
In-Reply-To: <ee77f5c20710270116g45a644bp2b6783310e16ff20@mail.gmail.com>

On Oct 27, 2007, at 10:16 AM, David Symonds wrote:

Show 21 quoted lines

> On 10/27/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> Rebase has definitely benefits but not all of its details
>> are obvious at a first glance. Tell a newbie to read the
>> git rebase man page and explain what git reabase does and
>> you know what I mean. Rebase definitely can help to create a
>> cleaner history. But it rewrites history and therefore destroys
>> information, for example information about the original code
>> base a patch was developed against, or merge conflicts that
>> were resolved. You also need to decide when to use rebase and
>> when to use merge. So you need to make a choice.
>>
>> Why not always use git merge?
>
> I'd use git-rebase for when I'm sending stuff upstream that I don't
> want to force the maintainer to merge, because I can probably do it
> better and quicker by rebasing. Once that's done, the upstream
> maintainer can just do a git-am (or similar), and it'll apply neatly
> on top of the current head. In other words, git-rebase allows the
> "merge effort" to be shifted to the brancher and away from the
> mainline maintainer/developer.

That definitely makes sense.

But you may need to do more merging because you need to merge every single commit. It may be easier to merge only the final state of a topic branch.

Could we somehow send rerere information together with a patch? This would give the upstream maintainer (and everyone else who wants to test the patch) the help needed to do a merge.

	Steffen