Jonathan Perkin <jperkin%joyent.com@localhost> writes: >> I think it would be good if mkpatches declined to update patchfiles if >> they weren't actually meaningfully different, at least by default. I >> find it annoying when I run mkpatches and e.g. see 12 .orig files, when >> examination shows that really there's just the new patch I added and 3 >> that were defuzzed, with 8 unchanged. >> >> I guess this comes down to suggesting that mkpatches be "mkpatches; >> patchdiff". Does anyone ever want to not have this behavior? > > Me. In my opinion patches should always be appropriate to the version > currently in pkgsrc, and it should be up to the person who updates the > package version to ensure that they are, rather than relying on fuzz. > > This helps a great deal when fixing packages without bumping the > version. It means that the diffs resulting from mkpatches are only > those which are caused by your change, and that makes it much easier > to verify that you aren't accidentally changing something else. I think there are multiple cases, and we may be talking about different things (due to me being unclear): a: patch is actually different b: defuzz only (with possible datestamp change) c: change of datestamps only d: no actual change (patch-foo and patch-foo.orig are identical) I don't want mkpatches to ever change patch files for category d. Right now I get the original patchfile moved to patch-foo.orig and a byte-for-byte-identical patch-foo witha new mod date. That's just noise/mess. For category c, I also don't want a change. I don't know why anyone would. For category a, a change is necessary. So the only interesting case is b, and I can see reasons to do it either way sometimes, as you say. So if mkpatches --no-defuzz changed category a only, and mkpatches changed category a and b, and mkpatches --regenerate-timestamps did a, b and c, would we all be happy?
Attachment:
pgpFLUCaju9kW.pgp
Description: PGP signature