On Sun, Jul 10, 2016 at 10:30 AM, FRIGN <[email protected]> wrote: > On Fri, 8 Jul 2016 13:14:30 -0800 > Britton Kerin <[email protected]> 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!
Good point. I guess it depends if you put the emphasis on clarity for first encounter in the patch page or on order in the user's collection later. I still favor optimizing for the patch page, since that's what people encounter first and other systems are likely to predominate later (e.g. all the patches I use go in my own repo anyway). I'll just do it the way you guys want. > 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. To me the availability of patches in the current format implies that they are curated and cared for, and I don't trust automated systems like this to work right. I'd rather just see a patch again an old version. > 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'. I liked having -git_ in there. (I see later you decided to omit). Maybe all suckless users are git versed but I doubt it. Seems like an example of expecting others to see the world like you do. The patch names are already verbose, why not make things explicit? Britton
