Re: [git patches] 2.6.x libata updates

[David Lang]

On Sat, 29 Oct 2005, Linus Torvalds wrote:

> On Sat, 29 Oct 2005, Jeff Garzik wrote:
> > Even so, it's easy, to I'll ask him to test 2.6.14, 2.6.14-git1, and
> > (tonight's upcoming) 2.6.14-git2 (with my latest pull included) to see if
> > anything breaks.
>
> Side note: one of the downsides of the new "merge lots of stuff early in
> the development series" approach is that the first few daily snapshots end
> up being _huge_.
>
> So the -git1 and -git2 patches are/will be very big indeed.
>
> For example, patch-2.6.14-git1 literally ended up being a megabyte
> compressed. Right now my diff to 2.6.14 (after just two days) is 1.6MB
> compressed.
>
> Admittedly, some of it is due to things like the MIPS merge, but the point
> I'm trying to make is that it makes the daily snapshot diffs a lot less
> useful to people who try to figure out where something broke.
>
> Now, I've gotten several positive comments on how easy "git bisect" is to
> use, and I've used it myself, but this is the first time that patch users
> _really_ become very much second-class citizens, and you can't necessarily
> always do useful things with just the tar-trees and patches. That's sad,
> and possibly a really big downside.
>
> Don't get me wrong - I personally think that the new merge policy is a
> clear improvement, but it does have this downside.
>
> 			Linus

how about setting up something on a webserver (ideally kernel.org) to do 
the git bisect and output patches against the daily snapshots.

if a lot of people used it the load would be an issue, but if it's only 
used by a relativly few people tracking down bugs it's probably worth it.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/