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