All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Sergei Organov <osv@javad.com>
Cc: "Besen, David" <david.besen@hp.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Amending merge commits?
Date: Mon, 28 Jul 2014 13:00:37 -0700	[thread overview]
Message-ID: <20140728200037.GN12427@google.com> (raw)
In-Reply-To: <87vbqhb7g9.fsf@osv.gnss.ru>

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.

When someone has made a merge by mistake (with 'git pull' before
remembering to do an autosetuprebase, or with 'git merge' instead of
cherry-picking some patches they needed), the current --rebase=true
behavior can be a good way of cleaning up.

That said, in some specific workflows, --rebase=preserve may work
better than --rebase=true.  My hunch is that even those workflows are
not currently handled well with --rebase=preserve, alas.

A clearer explanation of --rebase (maybe with sub-headings for each
choice *true*, *false*, and *preserve*?) sounds useful.  An
illustration in the EXAMPLES section of git-pull(1) of the difference
between these three modes and when to use them would be even more
helpful.

Thanks,
Jonathan

  reply	other threads:[~2014-07-28 20:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 22:03 Amending merge commits? 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 [this message]
2014-07-28 20:53           ` Sergei Organov
2014-07-28 21:47 Nico Williams
2014-07-29  9:58 ` Sergei Organov
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

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=20140728200037.GN12427@google.com \
    --to=jrnieder@gmail.com \
    --cc=david.besen@hp.com \
    --cc=git@vger.kernel.org \
    --cc=osv@javad.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.