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

From: David Symonds <dsymonds@gmail.com>
Date: Oct 27, 2007, 08:16 UTC
Message-ID: <ee77f5c20710270116g45a644bp2b6783310e16ff20@mail.gmail.com>
In-Reply-To: <8E86BDBA-A49A-49BB-8E00-8BF6DD7237E9@zib.de>

On 10/27/07, Steffen Prohaska <prohaska@zib.de> wrote:

Show 12 quoted lines

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

Dave.