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?
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?
I'm aware that you can do other things with git rebase that
cannot be achieved by using git merge. For example moving a
topic branch to a different stable branch without merging all
of the topic branch's history ("--onto" option). It is easy
to explain that rebase has it's own value.
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
