On Thursday, February 1, 2024 2:00 PM, Dragan Simic wrote: >On 2024-02-01 19:36, Hans Meiser wrote: >>> Could you, please, clarify what kind of git documentation are you >>> referring to? Are you having git man pages in mind? >> >> Yes, these in particular. >> >> From my point of view, many of these are quite unorganized, hard to >> read and – as I believe – need a fix-up. Markdown could replace the >> currently used language, so editing them would be more easy, proving >> support for preview and lint the documentation. > >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. > >>> Quite frankly, I think you've missed some important points from the >>> Konstantin's message. To sum it up a bit, not having continuous >>> support is simply unacceptable for any kind of a long-term project. >> >> As I wrote, once installed on-premise, no-one will shut down an >> on-premise git server except for yourself. It can run for eternity. >> You just need someone to administer it properly and publish the >> website. > >A git server? I was under impression that you proposed running an own instance of >GitLab or something similar. Git is unique, as a project, given that everything (! Not everything but a whole lot) is managed using git, including the enterprise git server platforms. A huge advantage of using a git server is being able to mirror the repository. If we went with a GitLab host, we could potentially mirror over to GitHub. The drawback is that the pull request history (and related discussions) id not (currently) preserved. I think this is a situation no matter what, even if we go GitLab/GitLab or GitHub/GitHub. The value of the discussion threads is the most important part of what needs to be preserved. I have high confidence that the team could move to either Pull Request/Merge Request structure reasonably easily, but if we had to move again in future (count on it), there must be a way to preserve the community assets of the discussions that went into making decisions. Without that, I am concerned that a migration to a GitLab (or any other) instance would increase velocity but put long term decisions at risk. >> In the end, it's all just about git. You may create your own git >> webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb), >> or just use an existing one, like the GitLab server: >> https://about.gitlab.com/install/ >> >> In these servers, everything is configurable. Moreover, many plug-ins >> exist for plumbing extensions to these providers. It's possible to >> establish your own workflow, rights management and automatic handling. >> You just need someone who is an expert with the tool of your choice. >> >> Many other great repositories already are using one of those >> providers; Meta, Google, Microsoft for example share their code there >> – just to name a few. I wouldn't consider these users as being known >> for being exceptional risk-takers. --Randall
