linux-kernel - Re: [PULL] vhost: cleanups and fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 May 2013 12:49:42 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	KVM list <kvm@...r.kernel.org>, virtualization@...ts.osdl.org,
	Network Development <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Asias He <asias@...hat.com>,
	target-devel <target-devel@...r.kernel.org>
Subject: Re: [PULL] vhost: cleanups and fixes

On Thu, May 2, 2013 at 12:33 PM, Michael S. Tsirkin <mst@...hat.com> wrote:
>
> I prefer not rebasing,

Good.

>                   will play with git to see why
> does request-pull get me a wrong diffstat and how
> to trick it into doing the right thing.
> Maybe merging my branch into master will do this.

No, don't do an unnecessary merge just to get the diffstat right.

git pull-request ends up assuming that there are no back-merges, and
that you have a uniquely defined single shared merge base. That allows
pull-request to just generate the diff directly from that merge base,
without actually trying to do the merge itself (which may have
conflicts etc).

But because git pull-request doesn't actually *do* the merge, it means
that it will fail to give the correct diffstat if the tree is
complicated and has multiple merge bases, and it can't really figure
what the original shared state was before the development.

This is just one reason I do *not* want to see back-merges. They make
history harder to read not just for humans.

You can either ignore the problem (I'll see the real diffstat when I
actually do the merge), or you can do a test-merge yourself (that you
do *not* then push out in the development branch - keep it in a
temporary branch for your own edification or just delete it after
doing the merge, and don't do development on it!)

In this case, it's an indirect back-merge: you back-merged a commit
from the target tree that I have now merged, so it has become a
back-merge. I'm not sure why you did that - if you needed to start
from that state, it would actually have been better to just start at
that state instead of merging it. But whatever. You can get the
diffstat by using your merge as the base, so

    git diff -M --stat --summary bc7562355fda..

in your branch should get the right result without any merges etc..
But please do send me a proper pull request.

              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/