From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Fri, 8 Jan 2010 14:50:23 -0800 Subject: [GIT PULL] omap fixes for 2.6.33-rc3 In-Reply-To: References: <20100108180912.GC6831@atomide.com> <20100108182236.GE6831@atomide.com> <20100108222715.GC2879@atomide.com> Message-ID: <20100108225023.GD2879@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Linus Torvalds [100108 14:38]: > > > On Fri, 8 Jan 2010, Tony Lindgren wrote: > > > > $ git log --pretty=oneline --author=".(none)" --committer=".(none)" v2.6.33-rc1.. > > Well, that will catch one particular common case of it, but.. > > > Should we have some check like this in place for all pulls? > > .. it would probably make more sense to warn about it earlier in the > chain, so that people with bad configurations can fix them. By the time > somebody pulls, it's pretty late in the game. > > Sadly, git doesn't do any real sanity checking, and now it's pretty much > too late. It takes about a year or two for new git versions to percolate > out, with things like Debian-stable etc, so making git warn about > suspicious-looking names is not necessarily going to help (and with > scripting and importing from other SCM's, it may be wrong to warn in > general). Yeah.. > It's _fairly_ easy to set up a hook at commit-time to check for random > thigns, but obviously if the problem is that people haven't configured > their git setup, then "add a hook" is not going to work. In that sense, > pull-time may be better, as a way to see it automatically after-the-fact. > > Doing a post-merge hook would catch it, and could be used to warn about > the fact that you merged something odd. Hmm, sounds like it might make sense to check for that in Stephen's for-next tree then. Added Stephen to the loop, let's see if what he thinks. Regards, Tony