All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Organov <osv@javad.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>, "Besen\,
	David" <david.besen@hp.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Amending merge commits?
Date: Tue, 29 Jul 2014 13:58:35 +0400	[thread overview]
Message-ID: <87r4147agk.fsf@osv.gnss.ru> (raw)
In-Reply-To: <CAK3OfOjr6ej5VdGU=bLmtag9cca1=ogLxVakCFTMG7b-A2uBiA@mail.gmail.com> (Nico Williams's message of "Mon, 28 Jul 2014 16:47:41 -0500")

Nico Williams <nico@cryptonector.com> writes:

> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Sergei Organov wrote:
>>
>>> Is there any scenario at all where pull --rebase=true wins over
>>> preserve?
>>
>> Basically always in my book. ;-)
>>
>> When people turn on 'pull --rebase', they are asking for a clean,
>> simplified history where their changes are small discrete patches in a
>> clump on top of upstream.
>
> +1.  Words to develop by.
>
> There are exceptions.  E.g., when you pull commits from multiple
> [forked] upstreams, then you can't keep your local commits on top.
>
> That exception aside, keeping all local commits "on top" by always
> rebasing them onto the upstream is extremely useful: a) in simplifying
> conflict resolution, b) making it easy to identify as-yet-unintegrated
> local commits, c) making it easy to contribute local commits.

But 'pull --rebase=preserve' does rebase local commits onto the
upstream, and result is exactly the same as 'pull --rebase=true', unless
you have some of your own merges to be rebased. That's where the
difference between these two options appears. It's --rebase=false that
performs merges rather than rebase.

Overall, I still can't see where '--rebase=true' wins over
'--rebase=preserve'.

-- 
Sergey.

  reply	other threads:[~2014-07-29  9:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28 21:47 Amending merge commits? Nico Williams
2014-07-29  9:58 ` Sergei Organov [this message]
2014-07-29 15:44   ` Nico Williams
2014-07-29 19:29     ` Philip Oakley
2014-07-29 20:19       ` Nico Williams
2014-07-29 21:38         ` Philip Oakley
2014-07-29 22:07           ` Nico Williams
2014-07-30  8:42     ` Sergei Organov
2014-07-30 17:43       ` Nico Williams
2014-07-30 18:28         ` Sergei Organov
  -- strict thread matches above, loose matches on Subject: below --
2014-07-25 22:03 Besen, David
2014-07-25 22:11 ` David Besen
2014-07-25 22:19 ` Jonathan Nieder
2014-07-25 22:23   ` Besen, David
2014-07-25 22:31     ` Jonathan Nieder
2014-07-28 19:37       ` Sergei Organov
2014-07-28 20:00         ` Jonathan Nieder
2014-07-28 20:53           ` Sergei Organov

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=87r4147agk.fsf@osv.gnss.ru \
    --to=osv@javad.com \
    --cc=david.besen@hp.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=nico@cryptonector.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.