Hi,
On Thu, 25 Oct 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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
-
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
