On Wed, Oct 27, 2010 at 12:57 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > 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. > Thanks for prompt answer. But let me clarify: When you do pull git performs: fetch of the remote branch to the FETCH_HEAD and then merge of FETCH_HEAD into the local branch What I'm saying is that your local branch should be rebased on top of FETCH_HEAD instead In this case there is no such thing as "often rebased public branch". if the history got diverged then pull will result in new state that should be tested anyway, so why not to rebase local branch on top of the upstream instead of merging upstream into local branch? i'm not saying to rebase the upstream published branch on top of the local changes - that's NO-NO I'm aware of thanks, Eugene -- 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