Re: [GIT] Networking
From: Steven Rostedt
Date: Tue Mar 15 2011 - 08:52:48 EST
On Tue, 2011-03-15 at 00:20 -0700, david@xxxxxxx wrote:
> > It really is meaningless to do so, as all you are doing is documenting
> > what commit caused this bug, and producing more problems by branching
> > off of the broken commit. It wont matter till it is merged, but then if
> > there are a lot of simple bug fixes, then you will have a lot of single
> > merges of branches that fix those bugs.
>
> what effect would this have on bisecting? if this helped people avoid
> bisecting in between the bad commit and the fix for it, it may be worth
> it.
>
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.
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.
-- Steve
--
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/