On Sat, 9 Dec 2006, Stefan Richter wrote: > Robert P. J. Day wrote: > > drivers/ata/pdc_adma.c | 4 ++-- > > drivers/macintosh/smu.c | 2 +- > > drivers/mtd/rfd_ftl.c | 2 +- > > drivers/net/phy/phy_device.c | 2 +- > > drivers/net/skge.c | 2 +- > > drivers/pcmcia/at91_cf.c | 2 +- > > drivers/pcmcia/omap_cf.c | 2 +- > > drivers/pnp/isapnp/core.c | 22 +++++++++++----------- > > drivers/pnp/pnpacpi/core.c | 6 +++--- > > drivers/pnp/pnpacpi/rsparser.c | 22 +++++++++++----------- > > drivers/pnp/pnpbios/core.c | 14 +++++++------- > > drivers/pnp/pnpbios/proc.c | 8 ++++---- > > drivers/pnp/pnpbios/rsparser.c | 16 ++++++++-------- > > drivers/scsi/sym53c8xx_2/sym_hipd.c | 2 +- > > drivers/usb/gadget/at91_udc.c | 2 +- > > drivers/usb/misc/uss720.c | 2 +- > > drivers/usb/net/rndis_host.c | 2 +- > > fs/ocfs2/alloc.c | 2 +- > > fs/ocfs2/cluster/heartbeat.c | 4 ++-- > > fs/ocfs2/cluster/nodemanager.c | 6 +++--- > > fs/ocfs2/cluster/tcp.c | 10 +++++----- > > fs/ocfs2/dlm/dlmdomain.c | 4 ++-- > > fs/ocfs2/dlm/dlmlock.c | 4 ++-- > > fs/ocfs2/dlm/dlmmaster.c | 2 +- > > fs/ocfs2/dlm/dlmrecovery.c | 6 +++--- > > fs/ocfs2/localalloc.c | 2 +- > > fs/ocfs2/slot_map.c | 2 +- > > fs/ocfs2/suballoc.c | 6 +++--- > > fs/ocfs2/super.c | 6 +++--- > > fs/ocfs2/vote.c | 4 ++-- > > include/linux/gameport.h | 2 +- > > kernel/relay.c | 4 ++-- > > net/sunrpc/svc.c | 2 +- > > sound/pci/hda/patch_realtek.c | 4 ++-- > > 34 files changed, 91 insertions(+), 91 deletions(-) > > This should really be split up and submitted separately. All the subsystems > are constantly changing. Although merging these kinds of changes manually > after eventual conflicts, it's still manual work for the maintainers which > would be avoided by a little bit extra work by the submitter. A maintainer > could get a merge conflict on a 100 lines long hunk because of an 8 lines > long hunk that got upstream on a different route.
fuck it, i give up. drop me a note when the grown-ups are back in charge. rday - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
