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!
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 <dev_AT_frign.de>
Received on Sun Jul 10 2016 - 20:30:44 CEST