MIME-Version: 1.0
In-Reply-To: <20170908143056.GA14724@flask>
References: <20170908143056.GA14724@flask>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 8 Sep 2017 15:25:58 -0700
Message-ID: <CA+55aFwg3t1F+032pHW3EfNLcG2omHsnkMTVorKESOjPyJNsFQ@mail.gmail.com>
Subject: Re: [GIT PULL] First batch of KVM changes for v4.14
To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        KVM list <kvm@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 1256
Lines: 29

On Fri, Sep 8, 2017 at 7:30 AM, Radim Krčmář <rkrcmar@redhat.com> wrote:
>
>  Topic branch merges in s390 and powerpc
> are already in mainline -- would you prefer to see the expected result
> after merge instead of what `git request-pull` produces?

So generally, if you do the test-merge anyway (which I appreciate), I
generally prefer the expected results instead of the raw `git
request-pull` output.

But it's also definitely not a hard requirement.

Basically, the rough guidance is that "git request-pull is sufficient".

And if you are not a git power-user (ie you don't use lots of
branches, and there aren't any shared topic branches with other
trees), git request-pull will simply always be the right thing anyway.

For maintainers that _are_ doing fancier things with git, and are
sharing branches and doing their own complex git history, "git
request-pull" is the simple interface - and is generally _too_ simple.
So then I _hope_ (but do not require) that such maintainers will do
the test-merge anyway for other reasons, and take the diffstat from
that instead, since the simple "git request-pull" model won't
necessarily give the right diffstat for the more complex history case.

So it's appreciated, but not required.

          Linus