I have set up a set of large Repositories (interlinked HTML-Documentation) and have these requirements:
- since they are large, i needed to split them up into multiple Repos
- Repos need to be checked out into a fixed Folder structure so the relative Links work
- users should be able to pick and check out individual repos
- all Repos have a simple, linear history with usually only 'main' branch
- The actual Version of each repo is not critical (unlike with Code), as long as the files are not moved (which is forbidden, users are asked to leave a forwarding tombstone)
- List item
This is what I have tried:
nested submodules: these quickly created conflicts with me, because they track the individual version of each sub-repo which is different in each clone. (Sub-question: are these conflicts 'normal'? Does this ever work in a distributed environment where submodules constantly change or it it a bad idea to use submodules?) We have started to no longer check in the upper/downstream Repos to avoid conflicts, but one result is that it is always 'dirty'
nested repositories in Folders marked as .gitignore: This seems to works and is sufficient, because the versions between individual repos are not critical. I wonder though if this is a good practice. Mind that cloning all sub-repos is a hassle, but individual users must be able to pick sub-sections. I think about checking in scripts to clone and pull whole sub-directories of repos, but is there maybe a better way?
subtrees: AFAIK these track the full history of the nested repos within the upper/root repo, which would be way too huge. Can someone comment on this?