[MPlayer-dev-eng] on breaking up patches ...
Diego Biurrun
diego at biurrun.de
Tue Sep 14 12:11:43 CEST 2004
This goes to everybody sending in patches:
Please send in patches as *ONE* patch, not n attachments.
The math should be pretty simple: n patches take n times longer to
apply, so they are n times less likely to be applied! OK, the time it
takes to apply a patch does not scale linearly with the number of
parts it is broken up into. But the most tedious steps do!
I'll try to show you an example shell session with me trying to apply
some random broken up patch, shell output is in [], thoughts in ():
silver:/usr/src/mplayer/main$ patch --dry-run -p0 < /tmp/foo_1.diff
[patch complains]
(Argh, why can't people just create patches with cvs diff?!)
silver:/usr/src/mplayer/main$ patch --dry-run -p1 < /tmp/foo_1.diff
[patch is happy]
silver:/usr/src/mplayer/main$ patch -p1 < /tmp/foo_1.diff
[patch is still happy]
silver:/usr/src/mplayer/main$ patch --dry-run -p1 < /tmp/foo_3.diff
[patch complains]
(Argh, why can't people just create patches from the root of the
source tree)
silver:/usr/src/mplayer/main$ cd XXX
silver:/usr/src/mplayer/main/XXX$ patch --dry-run -p1 < /tmp/foo_3.diff
[patch is happy]
silver:/usr/src/mplayer/main/XXX$ patch -p1 < /tmp/foo_3.diff
[patch is still happy]
Lather, rinse repeat for the next three parts of it and hope that they
all apply cleanly, else repeat with the -R flag (and yes, I sometimes
still forget to run all parts through --dry-run before applying some
parts).
Then there is the problem of inconsistent numbering. Should I really
apply foo1.diff, foo3.diff, foo4.diff, foo5.diff and not assume that
foo2.diff is missing somewhere?
And yes, I should update DOCS/tech/patches.txt and I will.
Diego
More information about the MPlayer-dev-eng
mailing list