On Aug 1, 2016, at 2:39 PM, Lawrence Velázquez <[email protected]> wrote: > Not to pick on you, Mihai, but have we ever considered getting rid of (or at > least revising) the guideline that implies that these new, sprawling, > indecipherable patch names are somehow more "correct" than the old ones? I > have never understood the point of including the name(s) of the modified > file(s) in the name of the patch itself, when this information is *already > inside the patch*.
The guide says: "Generally speaking, you should create one patch file for each logical change that needs to be applied. Patchfile filenames should uniquely distinguish the file and generally be of the form patch-<identifier>.diff, where the identifier is a hint of what the patch does. For example, this can be the filename of the patched file as in patch-src-Makefile.in.diff." So the filename is an example (and I would agree, a poor one) of what <identifier> could/should be. > And these aren't even the worst: Many patches are just named after the files > they modify, with no information about their purpose. I don't think I should > have to resort to version control to get the first inkling of a patch's > purpose. I'm sure I've been guilty of creating patch-Foo.c.diff files in the past too, and I agree it would be much better to choose a better identifier. -- Daniel J. Luke _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
