On Sat, 27 Oct 2007, Steffen Prohaska wrote: > There are some discussions going on about merge vs. rebase. The > suggestions by Dscho is to prefer rebase over merge in a > CVS-style workflow. > > 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? > > Is the only problem of git merge that it might create loops > in the history with potentially long running parallel lines > that are insufficiently visualized in gitk? > > If so, why not improve the visualization? > > Or is there any other deficiency of always using merge and > never using rebase that I don't see? Not all possible upstream systems support non-linear history. If upstream is actually svn or cvs, you need to rebase in order for the other system to be able to represent the result. I think it's easier for someone from the future trying to figure out the historical reason for some code to be a certain way if that code isn't touched by a merge conflict resolution. If there is a conflict, the resulting content is most directly due to a commit that has no explanation aside from a note that there was a conflict there; it's somewhat easier to understand if the code is entirely attributable to the commit that logically introduces the change. (Although maybe we could make the display take care of this; linearize the history using the rerere info in the merge commit, and show that as the history, annotated suitably to indicate that the blame for some of it falls partially on the merge commit.) It's also more familiar for many users to be asked to place their changes after all other committed changes, rather than leaving the ancestry pegged at the last time they updated before starting to work. > Obviously you can use git merge only if you want to have _all_ > changes from the other branch. But this is often what you > want. In a CVS-style workflow you want to merge all changes > from the shared branch before pushing. Why going through the > hassel of git rebase? Unless you've got a series of changes to a section that the upstream also changed, it's the same amount of resolution, but rebase lets you resolve logical collections of conflicts (i.e., those due to a single one of your commits) individually. IIRC, merging my builtin-fetch topic after 1.5.3 had 3 scattered conflicts, and rebasing had 4 conflicts, with no more than one per commit (so that I could test the resolutions independantly), and the rebase was easier. -Daniel *This .sig left intentionally blank* - 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
