On 1 August 2016 at 20:49, Daniel J. Luke wrote: > 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.
Generally I'm more happy to see at least some consistency than *totally random* names. Very often I simply have no clue how to name a patch, so I'm sometimes happy to just use the filename without giving any thought (often the file name tells a tiny bit about the type of patch). Then again, very often using the filenames is super weird and it helps to group the patches in a different way (split patches of the same file in multiple files; combine patches of multiple files into a single .diff file) and way less useful than some better description, but I admit that I feel at least a bit guilty when I pick a name different from filename due to a guideline that I once read somewhere. In the above example I would also prefer the old patch names. Mojca _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
