FWIW, I prefer 'git format-patch' output for patches. If I actually had to rename patches per file, maintaining llvm would be a nightmare. =/
> On Aug 4, 2016, at 05:35, Clemens Lang <[email protected]> wrote: > > FWIW, I agree with Lawrence here. I think we should improve our patch > naming, especially since it doesn't really matter *where* a patch comes > from, either. Why do we really need to know whether a patch-*.diff file > comes from MacPorts when compared to a different patch? We should be > judging patches by their content, not their origin. > > What I've seen in other systems and would also recommend as a guideline > for patches in MacPorts: > - Write a commit message into the patch file. Patch headers can include > arbitrary text, so type a message explaining what the patch does and > why it is needed. Add references to any upstream tickets (I've > started doing this for my ports according to OpenEmbedded's > Upstream-Status tag [1]). > - Use the summary line of the commit message as patch name, like git > format-patch does it. > > I have in the past also ignored our patch naming guidelines when I > thought it made sense; for example, I generally backport patches from > upstream git repositories using <commithash>.patch, because that's what > GitHub generates. > > [1] > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations > > -- > Clemens > _______________________________________________ > macports-dev mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
