git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] Teach 'git pull' the '--rebase' option
Date: Thu, 25 Oct 2007 16:54:58 -0700	[thread overview]
Message-ID: <7v3avy21il.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0710260007450.4362@racer.site> (Johannes Schindelin's message of "Fri, 26 Oct 2007 00:10:08 +0100 (BST)")

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.

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

  parent reply	other threads:[~2007-10-25 23:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-25 22:54 [PATCH] Teach 'git pull' the '--rebase' option Johannes Schindelin
2007-10-25 23:04 ` Linus Torvalds
2007-10-25 23:10   ` Johannes Schindelin
2007-10-25 23:36     ` Linus Torvalds
2007-10-25 23:49       ` Linus Torvalds
2007-10-25 23:54     ` Junio C Hamano [this message]
2007-10-26  9:52       ` Johannes Schindelin
2007-11-28  0:11         ` Junio C Hamano
2007-11-28 13:11           ` [PATCH v2] Teach 'git pull' about --rebase Johannes Schindelin
2007-11-28 13:15             ` Jonathan del Strother
2007-11-28 14:02               ` Johannes Schindelin
2007-11-28 13:19             ` Jakub Narebski
2007-11-28 20:35             ` Steven Grimm
2007-11-28 20:40               ` Johannes Schindelin
2007-11-28 21:10                 ` Lars Hjemli
2007-11-28 21:55                   ` Junio C Hamano
2007-11-28 21:58                     ` Johannes Schindelin
2007-11-28 22:06                       ` Steven Grimm
2007-11-28 22:33                       ` J. Bruce Fields
2007-11-28 22:47                         ` J. Bruce Fields
2007-11-28 23:12                           ` Johannes Schindelin
2007-11-28 23:32                             ` Junio C Hamano
2007-11-28 23:56                               ` J. Bruce Fields
2007-11-29  0:16                                 ` Johannes Schindelin
2007-11-29  8:36                               ` Andreas Ericsson
2007-11-29  3:23                         ` Nicolas Pitre
2007-11-28 21:59                     ` Jon Loeliger
2007-11-28 22:02                       ` Johannes Schindelin
2007-12-01 20:37                     ` Björn Steinbrink
2007-12-03 13:10                       ` Karl Hasselström
2007-10-26 11:43     ` [PATCH] Teach 'git pull' the '--rebase' option Jeff King
2007-10-26 11:45       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v3avy21il.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).