Re: [PATCH] Teach 'git pull' the '--rebase' option

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Thu, 25 Oct 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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.
> 
> Nits.
> 
> (1) This "operation" will "rewrite"  history.

Okay.

> (2) This is not suitable for people who publish their trees and
>     let others fetch and work off of them.
> 
>     Rebase is fine for e-mail submitting contributors as your
>     description above suggests, but as your proposed commit log
>     message said, it is also perfectly appropriate if your
>     interaction with the outside world is "fetch + rebase +
>     push".  You are not limited to "submitted to another
>     committer".

Well, originally I did not want to document it at all.  But I already 
heard the complaints about that in my inner ear.  So I documented it, 
sparsely, in the hope that those who do not know the implications will not 
dare to use it.  After Linus' complaint, I tried to make this shooing away 
more explicit.

I do not want to go into _that_ many details here, since the place to look 
for it is git-rebase.txt.  Probably I should have done that in the first 
place.

So how about this instead:

\--rebase::
        Instead of a merge, perform a rebase after fetching.
        *NOTE:* This is a potentially _dangerous_ mode of operation.  
	It rewrites history, which does not bode well when you
	published that history already.  Do _not_ use this option
	unless you have	read gitlink:git-rebase[1] carefully.

Hmm?

Ciao,
Dscho