mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Miller <davem@davemloft.net>
Cc: rdreier@cisco.com, general@lists.openfabrics.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	jeff@garzik.org, Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [GIT PULL] please pull infiniband.git for-linus
Date: Thu, 11 Oct 2007 19:58:04 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.999.0710111944120.6887@woody.linux-foundation.org> (raw)
In-Reply-To: <20071011.181719.78707713.davem@davemloft.net>



On Thu, 11 Oct 2007, David Miller wrote:
> 
> Even if you're confident there won't be merge issues, could you just
> wait for the net-2.6 stuff to go in first?

I pulled the net stuff first, and merged the IB stuff afterwards. No 
conflicts in IB, but there *were* conflicts with the networking pull for 
other reasons.

That horrid, horrid mess that is called include/linux/mod_devicetable.h 
and scripts/mod/file2alias.c must go at some point. The thing is 
unmaintainable. Different maintainers add their own structures to both, 
and functions to both, and it's just messy. That's not how maintainable 
and modularized code should be written.

Now it broke on sdio vs ssb, but there was actually a conflict earlier 
with the Kbuild merge (which I aborted for other reasons), so this file 
really is starting to be a problem.

The merge was fairly straightforward and stupid - it's not like the code 
added is *complicated*, but all those small functions and structrues are 
set up to be a maze of very similar lines, so the merge is actually much 
worse than it should be - because there is inherent similarity, some lines 
are automatically auto-merged, making the result just harder to visualize.

So I merged it all, and I don't expect any problems, but I'm hoping 
somebody is thinking about that mod_devicetable.h/file2alias.c mess.

I'm not entirely sure who to blame on that thing. I'm adding Greg to the 
Cc, on the assumption that blaming him is usually the right thing to do ;)

Oh, and obviously, the NAPI changes may well have resulted in a merge that 
had no actual *conflicts* in it, but whether the end result works or not 
(and whether any IB drivers need updating due to the NAPI changes), I 
cannot tell. I've pushed out my tree, so people who are competent or just 
morbidly curious should start looking at it: it's got the following things 
merged now:

 - x86 merge
 - mmc
 - v4l-dvb
 - blackfin
 - avr32
 - block layer updates
 - Jeff's dmi-const
 - Purdie's blacklight and led trees
 - ide
 - mips
 - net
 - infiniband

and it all builds for me, but hey, I don't use half of it.

Oh, btw, one final note: because of just a *ton* of renames, if you 
actually want git to do rename-detection for you and do automatic merges 
across those x86 renames, you should likely add

	[diff]
	        renamelimit=0

to your .gitconfig file. Otherwise, the rename detection heuristics may 
end up saying "I'm not going to even bother finding renames in that mess".

(That final note really shouldn't affect any normal users, but I thought 
I'd mention it in case somebody is going to want git to merge things 
across the x86 merge, and gets stuck not realizing why some versions of 
git might not notice the renames).

			Linus

  parent reply	other threads:[~2007-10-12  2:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12  1:08 Roland Dreier
2007-10-12  1:17 ` David Miller
2007-10-12  2:21   ` [ofa-general] " Roland Dreier
2007-10-12  2:36     ` David Miller
2007-10-12 13:07       ` Roland Dreier
2007-10-12  2:58   ` Linus Torvalds [this message]
2007-10-12  3:28     ` David Miller
2007-10-12  3:52     ` Greg KH
2007-10-12  4:03       ` Linus Torvalds
2007-10-12 22:19         ` Redesigning file2alias for easy merging (bits of kbuild/kconfig) Oleg Verych
2007-10-12 12:58     ` [GIT PULL] please pull infiniband.git for-linus Jeff Garzik
2007-10-13  1:10   ` Andrew Morton
2007-10-13 21:17 Roland Dreier
2008-01-03 18:29 Roland Dreier
2008-01-03 18:39 ` David Dillow
2008-01-03 18:56   ` Roland Dreier
2008-01-03 20:13     ` David Dillow
2008-01-03 20:20       ` David Dillow
2008-01-03 21:34         ` Roland Dreier
2008-01-03 23:11         ` Rik van Riel
2008-01-03 23:18           ` Dave Dillow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.999.0710111944120.6887@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=general@lists.openfabrics.org \
    --cc=gregkh@suse.de \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdreier@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®