<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=516917) </details> <!--IssueSummary end--> ### Release notes There are many cross repo version control strategies that are used in development that include the use of GIT utilities like `submodules`. Indeed, Gitlab actively supports `submodules` via its **`gitmodules`** interface. However, GIT Subtrees have their added advantages and use cases as well. I am proposing that support for Git Subtrees be added to Gitlab either as an additional component of `gitmodules` , as its own bespoke Gitlab interface or at the minimum a visual alert on the presence of a `Git Subtree` in Merge Request UI/UX sessions. ### Problem to solve As of the creation of this proposal, when development teams attempt to incorporate traditional `Git subtrees` within a Gitlab repo which makes use of CI/CD, the process can be a very cumbersome one: * The Gitlab Repo's `.git` does not correctly distinguish externally derived subtrees as subtrees; Git Submodules are treated far better. * MR/PR sessions are littered with extra `subtree` content that clutters actionable code changes related to the local repo itself, as the `.git` playhead picks up all changes by default, even externally sourced ones. * As a result, changes that are exclusive to the `subtree'd` repo appear to be local changes to the repo within the subtree exists and are tracked by the git `HEAD` as such. * Multiple `git` boilerplate commands must be used to `update` , `create` and `rebase` a typical `subtree` while much of the heavy lifting<span dir=""> </span>complexity of `submodules` is quietly simplified for the user via the `gitmodules` interface. ### Intended users **_All_** Gitlab users who: * Make use of Git Subtrees rather than or in addition to Git Submodules via `gitmodules` * Would like to ensure their users/teams can have an easy at-a-glance delineation of where code is sourced from when no changes are made to a `subtrees` content in a local repo. ### User experience goal At minimum, A user who has used a `Git Subtree` in their Gitlab repo should have * Their `.git` not hard track changes of a `subtree` unless a change was made to the contents of the subtree in the local repo it's been pulled into * I acknowledge this may be difficult to do. * At minimum, the ability to flag an added `subtree` (e.g. `git remote add -f [my-subtree] ``git@gitlab.com``:My/remote/repo/to/add.git && git subtree add --prefix [my-subtree] ...` ) for Gitlab Merge Request UI/UX de-cluttering. * Something like a simple bit of iconography or prompting text (like what is used to distinguish `LFS` files in a Gitlab Repo) would help to cite this for the code reviewer * Pre-folding/collapsing `subtree` code that was added which have NO LOCAL Changes within the local repo (e.g. auto-hide noisy code). ### Available Tier Ideally, this sort of functionality should exist at the same level of tier that the current `gitmodules` interface exists at. ### What is the competitive advantage or differentiation for this feature? No other Version Control System that uses GIT as its base currently does this as far as I know. ### Links / references