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

Johannes Schindelin [off-list ref] writes:

On Thu, 25 Oct 2007, Linus Torvalds wrote:

quoted

On Thu, 25 Oct 2007, Johannes Schindelin wrote:

quoted

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.

    You are not describing a command, but just one mode of operation
    of a command, whose other modes of operation do not share this
    history altering behaviour.

    The history is rewritten and made hard to work with for others
    who have previous incarnation of that history.  If it happens
    that nobody shared that previously published history nobody
    needs to suffer.  In that sense, there is something _usable_
    depending on who you are.  Destroy feels a bit too strong a
    word.

(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".

Hi,

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

Johannes Schindelin [off-list ref] writes:

quoted

On Thu, 25 Oct 2007, Linus Torvalds wrote:

quoted

On Thu, 25 Oct 2007, Johannes Schindelin wrote:

quoted

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