Eugene Sajine wrote: > So, why not to rebase? An interesting question. Rebasing results in untested commits. If this is a patch series for submission, that's fine, because you will be extensively testing each patch anyway or indicating to reviewers that that needs to be done (right?). But if it's a long-lived branch then such repeated testing work can be a serious hassle. https://git.wiki.kernel.org/index.php/GitFaq#What_is_the_difference_between_a_merge_and_a_rebase.3F A public branch that is regularly rebased is hard to follow ("git log foo@{1}..foo") and build on. http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_recovering_from_upstream_rebase Code consumers often want clean history, but that really means (a) clean and (b) history. http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744 Hope that helps. -- 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