On 2024-02-02 11:18, Hans Meiser wrote:
Please keep in mind that editing the git man pages requires very
intimate knowledge of the related git source code. Many times even
small changes to the language style can change the meaning and diverge
the man pages from the source code, making the man pages useless.
Sure. Eventually, I'd rather propose to have parts of the man pages be
generated from code comments (XmlDoc, JsDoc or similar), particularly
syntax and parameter list. That would keep documentation from
deviating from code right from the beginning. And it would keep
documentation writers from manually updating obvious parts.
That might work out in some places, but I'm not really sure about the
overall effectiveness. The git man pages don't document function calls.
A git server? I was under impression that you proposed running an
own instance of GitLab or something similar.
Basically, GitLab, GitHub, Azure DevOps are all just Git servers, plus
collaboration and automation functionality. I suggested using GitWeb
only in case you wanted to write (and keep control over)
collaboration and automation functionality yourself. Otherwise you may
use one of the existing ones that have already been written (i.e.,
GitLab, GitHub, Azure DevOps).
The plus brings additional issues. It's been already noted that
favoring
any of those solutions actually wouldn't be in the interest of git
itself
as a project, because it wants to remain neutral.
IMHO, these days too much is expected to be handled by "something else",
instead of the developers handling that. It's like offloading the
basically
unavoidable complexity to some utility, and expecting that the
complexity
will somehow go away.
In other words, a developer has to keep quite a lot in their short-term
memory, and a lot in their long-term memory, to be able to accomplish
some
task, and hardly any utility is going to make that significantly easier.
The same principle, in general, applies to a group of developers working
on the same task.
