Re: [GIT] Networking

[J. Bruce Fields]

On Tue, Mar 15, 2011 at 08:52:40AM -0400, Steven Rostedt wrote:
> But it wont, as the fix will still be brought in at a later time. It has
> nothing to do with being based off of the broken commit.
> 
>          A  +
>             +   merged in fix
>          B  + \
>             |  |
>             |  |
>             |  |
> Lots of     |  |
>   stuff     |  |
>             |  |
>             |  |
>             |  + - fix for bug
>             | /
>  Bug commit +
>             |
> 
> A bisect will still be testing lots of stuff without that fix. And if it
> goes into the branch with the fix, we just brought the kernel way back
> in time from point A. Then if it goes back to point B, then we zoom back
> to the future and bounce the kernel all over the place.
> 
> I see no gain for having a fixed based off of the bug that it fixes.

I suppose you'd test the intermediate ("bad") area by merging in "fix
for bug" instead of cherry-picking it.  In theory perhaps that would
give the bisect algorithm a little more information.  (Since it's seeing
the same "fix for bug" commit each time.)

> Pros of doing this:
> 
> 1) documents the point that things broke (can be done by commenting it
> in the change log too)
> 
> 2) probably good for back porting (but Con 3 may out weigh this)
> 
> Cons:
> 
> 1) Adds many more branches and merges for no real good reason
> 
> 2) Makes bisects even less linear than it already is
> 
> 3) May cause more conflicts at the merge point as the broken code may
> have changed.
> 
> 
> 
> Who will be doing the conflict resolutions? Linus? I doubt he would be
> happy with that, but he can speak for himself.

No real change there: you still won't want to send in a pull request
every time you fix a bug, so you'd pull a bunch together, merge them
(and maybe a test merge with upstream to make sure it's reasonable),
then send a pull request for the result.

I dunno, I have no strong opinions here, just curiosity.

--b.
--
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/