On 01.08.2016 08:39 PM, Lawrence Velázquez 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*.
There are multiple points to this guideline. Starting with "patch-" and ending in ".diff" probably is a good one, because we can easily distinguish MP patch files from other contrib files. Just ending in ".patch" might also be possible, but an ending is less obvious than a fixed start. I kinda like that one. Then, the identifier. As already pointed out by others, there's no fixed guideline as to what this should be comprised of, although the example seems to mandate including the file name. > 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. Using the file name/path alone as the identifier is something I am (and you are) personally strongly against, because I *still* don't know what it's good for just by looking at it. Instead, I like to have a (short) description included in the identifier. The other side of the coin, of course, is that this inevitably leads to "sprawling", complex file names. Still, I think that's better than not knowing what a patch is for. Including both file names and description is probably my own quirk stemming from my convention of naming git commits/writing up the first line of a git commit: filenames (as compact as possible): description. Most of the time, this can be written quite compactly, although sometimes it does tend to blow up. Because I try to avoid special characters in file names, the "blowing up" situation is even worse there. And yet that helps me determining the patch order or rather dependencies within patches. Yes, it's redundant information, but more concise than opening a patch file and finding out what real files that patch changes or grepping for headers. Mihai
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
