On Mon, 1 Mar 2010 10:07:14 +0100, Uwe Kleine-König wrote:
> On Sun, Feb 28, 2010 at 03:57:54PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 24, 2010 at 12:01:46PM +0100, Uwe Kleine-König wrote:
> > > Signed-off-by: Uwe Kleine-König <[email protected]>
> > > Acked-by: Jean Delvare <[email protected]>
> > > ---
> > >  MAINTAINERS |    1 +
> > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 2533fc4..a3c936c 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -2626,6 +2626,7 @@ M:  "Ben Dooks (embedded platforms)" 
> > > <[email protected]>
> > >  L:       [email protected]
> > >  W:       http://i2c.wiki.kernel.org/
> > >  T:       quilt 
> > > kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
> > > +T:       git git://git.fluff.org/bjdooks/linux.git
> > 
> > This is wrong.  This is the same tree which I pull ARM stuff from, so it
> > needs qualifying with a branch name.
> $(git ls-remote git://git.fluff.org/bjdooks/linux.git) suggests two
> candidates:
> 
>       for-linus/i2c
>       next-i2c
> 
> And I think for now this is only parsed by humans and everbody should be
> able to notice that e.g. "next-s3c" doesn't contain i2c patches in the
> presence of the two above branches.
> 
> So unless there is a syntax to specify more than one branch I suggest to
> keep it as is.  Or should we only list next-i2c?  Ben, what do you
> think?

I presume that for-linus/i2c is a temporary subset of next-i2c for
Linus' consumption. So we can ignore for-linus/i2c and only list
next-i2c.

> (Maybe we can just make it:
> 
>       T: git git://git.fluff.org/bjdooks/linux.git for-linus/i2c
>       T: git git://git.fluff.org/bjdooks/linux.git next-i2c
> 
> but this is a bit too much IMHO.  (Who volunteers to list all branches
> of tip in MAINTAINERS? ;-))
> 
> Best regards
> Uwe
> 


-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to