On Sun, Jul 10, 2016 at 10:30 AM, FRIGN <dev_AT_frign.de> wrote:
> On Fri, 8 Jul 2016 13:14:30 -0800
> Britton Kerin <britton.kerin_AT_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!
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
Received on Wed Jul 13 2016 - 02:19:40 CEST