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).
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.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
