Context

I’m using a self-hosted instance of GitLab to maintain projects of multiple different customers and multiple different topics per customer using subgroups. This looks pretty much like the following:

• customer_1
  • archive
    • bin
    • src
  • bin
    • deployment_1
    • deployment_2
  • library
  • src
    • topic_1
    • topic_2
• customer_2
  • […]

So by convention, all of those customers get some individual library project to maintain things like file templates for LibreOffice, image files for logos, icons and stuff not related to individual projects of the customer, but e.g. the whole company. Additionally, the wiki associated with the library project is expected to contain docs related to the whole company, possibly concepts like how the IT should be refactored etc.

Problem: Non-textual files to “support” text

And here’s the problem: While I very much like the content focused rendering of the wiki-repo, I really often need to maintain additional files like PDFs for the texts I write into the wiki. Some are only part of the research which resulted in the text, but don’t need to be explicitly mentioned/linked in those texts. The important thing is to have them and possibly have a lok at those at some point in the future.

That’s not a problem for devs like me able to simply clone the wiki-repo and browse it using some file manager. I see somewhat usefully named files and directories and what’s contained. Even the written Markdown or AsciiDoc isn’t too much of a problem as rendering plugins exist for editors and IDEs. But that’s not as easy the case for other people which I sometimes would e.g. like to send links to files or directories which images which would be then shown within their browser.

That is often exactly what is possible with the default repo of a project and it’s web-UI. That repo can be browsed using a browser, some files can be looked at etc. Therefore I started to place mainly texts into the wiki-repo and files into the library-repo itself, so that I’m able to send links to those files. Though, I have two places now where I need to maintain things, while one repo would be enough in theory. Additionally, the content editor for the wiki itself doesn’t support such things, it uploads e.g. files into its own repo for the wiki only.

Solutions?

Would be great to have either of two things: Make the wiki-repo additionally available like the main project repo in the web-UI or simply use one and the same repo for both only instead of two individual repos.

Is anything like that possible? Doesn’t look like it is using the web-UI. Would it be possible by low-level changes like symlinking repo dirs or alike?

Thanks!

I had an additional look at the web-UI especially of the main source repo and decided to got with that instead of the wiki currently. The web-UI and web-IDE render AsciiDoc and Markdown pretty fine as well, even including referenced images, but the default repo web-UI has much better linking support for browsing and linking.

Even if one changes ones mind, things should be easy in the end, as the other repo can simply be added as a remote, fetched and merged/cherry picked as necessary. While TortoiseGIT warns/errors about unrelated history, one can still merge and therefore easily forward commits between repos.

The only real downside I see currently is that the web-UI of the main source repo might overwhelm non-developers. The UI of the wiki seems to be more focused on those and textual content creation only.