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: Wed, 30 Jul 2014 12:42:58 +0400	[thread overview]
Message-ID: <87siljxmnh.fsf@osv.gnss.ru> (raw)
In-Reply-To: <CAK3OfOhFzbUA7gZbox84W=VC+0aSuiNc-XRP_MTyYy1UeFFzZQ@mail.gmail.com> (Nico Williams's message of "Tue, 29 Jul 2014 10:44:11 -0500")

Nico Williams <nico@cryptonector.com> writes:

> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov <osv@javad.com> wrote:
>> Nico Williams <nico@cryptonector.com> writes:
>>> 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.
>
> Local merge commits mean that you either didn't rebase to keep all
> your local commits on top of the upstream, or that you have multiple
> upstreams (the example exception I gave).

I rather have multiple (release) branches on single upstream, say, v2.3
and v2.4. When something needs to be fixed in 2.3, it's fixed there and
pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is
pushed upstream. When I do this merge, I need to push the merge
upstream, and this won't work reliably when --rebase=true is acitve
(through pull.merge=rebase). If nothing changes upstream, I can simply
push this, and the merge is correctly preserved. However, if somebody
makes any changes upstream while I perform the merge, I'll need to pull
before pushing, and this immediately flattens-out my merge, that is
absolutely not what is needed here. Or I can simply pull before push,
just in case, and this flattens history even when there are no any
changes upstream!

Once again, nobody yet gave any clue of when/why pull.merge=preserve
configuration is inferior to pull.merge=rebase, as for all the scenario
you seem to care about they bring the same result.

> Conversely, if you always rebase your local commits on top of the
> upstream then you won't have merge commits to worry about.

Wrong. I do alwys rebase my local commits on top of upstream, but I
still do have my own merge commits to worry about, as explained above.

-- 
Sergey.

  parent reply	other threads:[~2014-07-30  8:43 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
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 [this message]
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=87siljxmnh.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.