On Fri, Oct 26, 2007 at 12:10:08AM +0100, Johannes Schindelin wrote: > Fair enough. > > How about this in the man page: > > \--rebase:: > Instead of a merge, perform a rebase after fetching. > *NOTE:* Never do this on branches you plan to publish! This > command will _destroy_ history, and is thus only suitable for > topic branches to be submitted to another committer. Reasonable, although perhaps it should mention what I suspect might be a common workflow for this feature: CVS emulation. I.e., there is a central repo, which is the only thing considered "published". Developers make commits in their local repo, and then rebase their changes onto the HEAD before pushing. The only difference from CVS is that you don't actually get to commit in CVS, you have to do the rebase with your working tree. :) I'm imagining a "pull.rebase = 1" config option, and handing this out to developers accustomed to CVS. -Peff - 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
