On Thu, Mar 02, 2006 at 09:12:23PM +0000, David Howells wrote:
> No. It has to be permissable to make a series of patches that depend one upon
> another for at least three reasons:
>
> (1) Patches can be unmanageably large in one lump, so splitting them up is a
> sensible option, even through the individual patches won't work or even
> compile independently.
That breaks git-bisect.
> (2) It may make sense to place linked changes to two logically separate units
> in two separate patches, for instance I'm changing the core kernel to add
> an extra argument to get_sb() and the get_sb_*() convenience functions in
> one patch and then supplying another patch to change all the filesystems.
>
> This makes it much easier for a reviewer to see what's going on. They know
> the patches are interdependent, but they can see the main core of the
> changes separated out from the massively repetative but basically less
> interesting changes that are a side effect of the main change.
It's also much easier to read a series of patches if each patch depends
only on the previous patches. Then if I want to verify that they don't
break anything, I just need to read them through in order and verify
that each one is correct.
If earlier patches depend on later patches, then I may not be able to
verify correctness until I've read and understand the whole series,
which defeats somewhat the purpose of splitting up the patches. Though
the above example wouldn't really be a problem.
And of course it seems rather silly to complain about splitting out a
function before adding the new caller.
--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
