Hi, On Thu, 25 Oct 2007, Linus Torvalds wrote: > On Thu, 25 Oct 2007, Johannes Schindelin wrote: > > > > This behavior is more desirable than fetch + pull when a topic branch > > is ready to be submitted. > > I'd like there to be some *big*warning* about how this destroys history > and how you must not do this if you expose your history anywhere else. > > I think it's a perfectly fine history, but if you have already pushed out > your history somewhere else, you're now really screwed. In ways that a > *real* merge will never screw you. > > So the "--rebase" option really is only good for the lowest-level > developers. And that should be documented. 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. Ciao, Dscho - 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
