On Oct 27, 2007, at 10:16 AM, David Symonds wrote:
On 10/27/07, Steffen Prohaska <prohaska@xxxxxx> 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
-
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
