On Fri, 8 Jul 2016 13:14:30 -0800 Britton Kerin <britton.ke...@gmail.com> wrote:
Hey Britton, > This was the agreed format but in a way it's a change for the worse. > It splits the thing patched against (prog+version) into two parts and > puts the patch name in between. To see why this is bad consider > http://st.suckless.org/patches/scrollback which stacks some patches on > top of each other to get different behaviors. Obviously we want the > patches to be mostly flat but that use case is reasonable. > It would be better to be consistent st > > st-scrollback-git-20160620-528241a.diff > st-scrollback-mouse-git-20160620-528241a.diff > > was instead: > > st-git-20160620-528241a-scrollback.diff > st-git-20160620-528241a-scrollback-mouse.diff > > This way things appended to the base name always represent > modifications of what comes before. No, this is not better. It makes sense if you only look at a patchset alone, but it's a bloody mess if you have multiple patch files, like many people do! A filename always has to satisfy a hierarchy. The most important information is which project it applies to, in this case "st". So we can all agree that this is the first part of the patchname. The second part is which patch we are talking about. It definitely should be the patchname itself, in this case "scrollback" or "scrollback mouse". The third part is the version. You either have one tagged against a fixed version, like st-scrollback-3.1.diff or a git version, which requires more information st-scrollback-git-20160620-528241a.diff Given we are currently in the process of automating the "maintainership" of patches, we will think about simplifying the git naming scheme in the future and maybe only including the git shorthash as a handle. The reason behind this is that if we have a githook automatically updating the patches on each git commit to st, dwm and so on, the date will be meaningless. However, we have many people here who are scared of rapid change. Some people suggest omitting the "git" in the filename of the diff, however, this is not an ideal solution. If you have many patches of one kind, the sorting will be all wrong. The "2016..." in a alphanumerical sorting (e.g. filename) will always be between fixed tag versions 2.x and 1.x. This is not desired. We can use the "git" tag and always be sure that it will be last, as numbers are usually preceding over letters like 'g'. > There are still lots of renames that have to be made by hand, broken > patches to contend with, etc. but I thought I'd ask one more time if > we're sure we're happy with this naming scheme. Yeah, let's do this! :) Think about the users and don't worry too much. Cheers FRIGN -- FRIGN <d...@frign.de>