Le 21/01/2025 à 00:43, Junio C Hamano a écrit : > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> On 2025-01-20 at 20:37:10, Jean-Noël Avila wrote: >>> Maybe for users of the end product of the documentations compiled here, >>> but there are other users who use the source files and this change >>> breaks their workflow pretty bad. I am one of those users for the >>> git-scm.com website and the manpage translation projects. >> >> I appreciate that this is a big change, but we do also sometimes make >> those and contributors and downstreams need to change over eventually. > > Yup. FWIW, this change would break my private toolings by renaming > things under Documentation/RelNotes/, which I did not think we even > pass through AsciiDoc, even though by inertia I write something akin > to AsciiDoc in these release note files. That's what I had in mind when advocating a bit of caution on this change. I'm not opposed to the change, because indeed, the original file extension pushed me to change the editor's configuration, which is cumbersome and may hinder newcomers on helping with the documentation. But to be honest, it's only because I'm monitoring the list these days that I stumbled upon this patch series. Some other consumers of the documentation source files may miss it and just discover the change after the fact. > > In this particular case, I would imagine that the use cases of > myself and Jean-Noël would _eventually_ want to be adjusted to deal > with anything the upstream picks as the file extension that may or > may not be ".txt" (to put it differently, they are written to expect > that these files end with ".txt", but the _ONLY_ reason why they are > is because those files in my tree _happen_ to have such names). We > certainly do not want to make a change like this unnecessarily and > unannounced. But with sufficient advance warning and enough time to > prepare transition, it shouldn't too bad. Agreed. > > Perhaps it may be enough keep the topic cooking a lot longer in > 'next' than usual one calendar week. This of course requires that > those on the creator side echosystem are paying attention to 'next', > are capable of writing necessary adjustment (in my case, I would > tweak my tooling so that it uses "$filename.$suffix" instead of > hardcoded "txt" in the rest of the script, checks the presence of > Documention/git.adoc to tweak suffix from default "txt") for their > tooling, and can arrange to test their tooling with 'next'. For git-scm, IIRC, present and previous versions of the manpages are processed, so the import script must manage both extensions. Fair enough, not an impossible task.
