linux-kernel - Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.6-1 tag

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:	Sat, 19 Mar 2016 15:57:48 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Michael Ellerman <mpe@...erman.id.au>
Cc:	Igal.Liberman@...escale.com, Zhiqiang.Hou@...escale.com,
	adam.buchbinder@...il.com, aik@...abs.ru,
	alessio.bogani@...ttra.eu, andrew.donnellan@....ibm.com,
	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Boqun Feng <boqun.feng@...il.com>,
	Balbir Singh <bsingharora@...il.com>,
	chenhui.zhao@...escale.com,
	Christophe Leroy <christophe.leroy@....fr>,
	clombard@...ux.vnet.ibm.com, cyrilbur@...il.com,
	david@...son.dropbear.id.au, dongsheng.wang@...escale.com,
	dougmill@...ux.vnet.ibm.com, Torsten Duwe <duwe@....de>,
	duwe@...e.de, fbarrat@...ux.vnet.ibm.com,
	gwshan@...ux.vnet.ibm.com, Ian Munsie <imunsie@....ibm.com>,
	Jeremy Kerr <jk@...abs.org>, joel@....id.au,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	leoyang.li@....com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	luis.henriques@...onical.com, maddy@...ux.vnet.ibm.com,
	manoj@...ux.vnet.ibm.com, Michael Neuling <mikey@...ling.org>,
	mrochs@...ux.vnet.ibm.com, oss@...error.net,
	Paul Mackerras <paulus@...abs.org>,
	Paul Mackerras <paulus@...ba.org>, qiang.zhao@....com,
	raghav.dogra@....com, ruscur@...sell.cc, saurabh.truth@...il.com,
	sjitindarsingh@...il.com, stewart@...ux.vnet.ibm.com,
	sukadev@...ux.vnet.ibm.com, vaibhav@...ux.vnet.ibm.com,
	Richard Yang <weiyang@...ux.vnet.ibm.com>,
	xinhui.pan@...ux.vnet.ibm.com, xuelin.shi@....com
Subject: Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.6-1 tag

On Fri, Mar 18, 2016 at 5:07 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
>
> I couldn't convince git request-pull to generate a sane diffstat below, it
> seems to be confused because I merged powerpc-4.5-4 into my next.

Yes, if there are multiple merge bases (particularly cross-merges, but
you can get it just from internal merges of work that started at
different points), a plain "git diff" will often be unable to give
reasonable results.

> So I just did the merge and took that diffstat. Hopefully that makes sense.

Yes, that's the way to get a reliable diff if you have more complex history.

Some people do that merge by default (ie both the networking tree and
the ARM SoC trees tend to do this), not just to get the reliable diff,
but also to inform me of the conflicts that they encountered.

So it's actually "good practice", as long as you then send me the
pre-merge state - I still want to do the merge myself to see what's
going on.

Exactly like you did, in other words.

At the same time, it's absolutely not required. So if the diffstat
looks odd, you can just send me the incorrect diffstat and just tell
me so.  Yes, I will get a different diffstat when I do the merge, but
I can still tell that it's what you intended to send me by just doing
the non-merge diff.

In general, the trees I pull tend to fall into two main camps:

 (a) "simple history" maintainers

     These maintainers don't pull from sub-maintainers, and that don't
ever hit the issue with "plain git diff cannot give the right end
result".

     The plain "git diff" that pull-request does always works for the
simple history case, and I really don't expect these maintainers to do
merges for me anyway, since they should have linear history and just
generally use a simplified git model.

     In fact, I will complain loudly if they start doing odd things
like cross-merging etc, because they really really shouldn't, and they
aren't ready and aware of the pain they cause.

 (b) the "complex top-level maintainer"

     This group does pulls of their own from submaintainers, and can
have fairly complex histories just within their own tree.

     This group can encounter the "oops, I don't have a simple merge
base, so 'gid diff' will not give sane results" situation.

     This group is also usually savvy enough that they then can handle
it and do the whole "let's do a test merge to see what conflicts I
get, and get a good diff even if there are multiple merge bases".

Of course, it's not _really_ that black-and-white, but it's a
simplified model and close enough.

Basically you should never hit that complicated case unless you are
already using workflows that means that you can handle it, and by then
you usually also end up understanding why clean history and avoiding
back-merges is a good idea etc.

Welcome to that second group.

               Linus