linux-kernel - Re: linux-next: please clean up the hid tree

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] [day] [month] [year] [list]

Message-ID: <20160714012438.2468f816@canb.auug.org.au>
Date:	Thu, 14 Jul 2016 01:24:38 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: please clean up the hid tree

Hi Jiri,

On Wed, 13 Jul 2016 11:21:36 +0200 (CEST) Jiri Kosina <jikos@...nel.org> wrote:
>
> On Wed, 13 Jul 2016, Stephen Rothwell wrote:
> 
> > The hid tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git#for-next)
> > seems to be based on v3.19 and constists of a large number of merges
> > (of stuff that is now in Linus' tree) and ends with one particulary
> > large revert (of a merge).  
> 
> I try to keep the tree completely non-rebasing, as people are actually 
> using it for development. But for-next is a bit special in this respect, 
> and if there is a branch that could potentially be considered for 
> ocasional rebasing, it's probably for-next one.

The non-rebasing bit is good if your branch is exactly what goes
upstream because if (after it is merged by upstream) you do a back
merge of upstream, that merge will just fast forward your branch and
your tree will be empty  - all with no rebasing.  In the case of your
for-next branch, that is not what is happening.

> OTOH, what issues exactly are the extra merges causing for you please?

Well, if you have a look at the diffstat of the last revert of a merge,
you get this:

$ git diff --stat hid/for-next^..hid/for-next
 .mailmap                                           |   4 -
 Documentation/ABI/testing/configfs-usb-gadget-uvc  |  58 ++---
 .../ABI/testing/sysfs-bus-iio-proximity-as3935     |   2 +-
 Documentation/scsi/scsi_eh.txt                     |   8 +-
 MAINTAINERS                                        |  13 +-
 Makefile                                           |   4 +-
 arch/Kconfig                                       |   7 +-
 arch/alpha/include/asm/pgalloc.h                   |   4 +-
	.
	.  Lots elided
	.
 sound/hda/hdac_regmap.c                            |   4 +-
 sound/pci/hda/hda_tegra.c                          |  20 +-
 sound/pci/hda/patch_realtek.c                      |   6 -
 .../ftrace/test.d/trigger/trigger-hist-mod.tc      |   9 +-
 .../ftrace/test.d/trigger/trigger-hist.tc          |   9 +-
 .../ftrace/test.d/trigger/trigger-multihist.tc     |   9 +-
 tools/testing/selftests/vm/compaction_test.c       |   2 +-
 tools/vm/slabinfo.c                                |   2 +-
 404 files changed, 2141 insertions(+), 3636 deletions(-)

So that git sees that you have this enormous change in your tree ...

Also, the more merges your tree contains and the further back it is
branched, the harder git has to work to do the merge against the other
trees I have and Linus' tree.

> Ok, this is pretty odd. I'll look into what happened, it'll be resolved in 
> a couple minutes, so please start pulling for-next again.

See above.

Anyway, thanks for the cleanup, the tree looks much better now.
-- 
Cheers,
Stephen Rothwell