Hi Brooke, On Wed, 17 Nov 2021, Wallace, Brooke T (US 349D-Affiliate) wrote: > Has any one considered adding a config spec feature to Git or does Git > alreadt have some way to support the same features? Since config specs are clearly not (yet) a Git feature, it would make sense to begin the discussion with a description of the concept of config specs, as the majority of the readers on the Git mailing list will be unfamiliar with them. > I've been using Git for a while now for small projects but taking on a > new larger project I've come to realize that Git does not have config > specs and so seems to be missing an important feature for managing large > projects. > > We use configuration specs to select directories from a common code base > (repo) and map them into different baselines to creat multiple product > builds with different feature sets. We used this feature in VCSs such as > Clearcase and Perforce. Ultimately this allows us to manage the repo in > one directory structure and create product builds with a different one. > For example the repo has multiple directories for different > products/targets, but a baseline, the workspace, has only one target > directory always with the same name mapped to the same location. > Obviously the corresponding directories in the repo have different > names. So from what I gather after reading this, I suspect that you have a main branch with a full tree, and you want to have a way to check out only parts of the tree. This concept has been brought up before, in https://lore.kernel.org/git/pull.627.git.1588857462.gitgitgadget@xxxxxxxxx/: proposing a way to define what parts of the tree should be checked out in a sparse checkout. However, it looks as if your config specs also allow to map the directories in the Git revisions to different locations and maybe even names? Such a concept has not come up on the Git mailing list. There _have_ been ideas floating around in Git for Windows, mainly to allow for checking out revisions that rely on file names that are illegal on Windows (such as file names containing backslashes, or reserved names such as `aux.c`). Nothing came of those ideas, though, mainly because nobody snatched up the baton to work on a concrete patch to implement this. I should point out, though, that the concept of a sparse checkout is independent from the concept of mapping file/directory names in the Git revision to different ones in the Git worktree. > Git supports the notion of submodules, but I see no way to map a > submodule directory to a different name, remove unwanted subdirs of a > submodule, or map a submodule over a subdirectory of the primary repo. > Config specs also allow you to specify a specific branch or version that > you want to map to your workspace independent of other directories, > branches and versions. The idea of letting directories in the same Git worktree originate from _different_ revisions is very, very foreign to the fundamental Git concept of what constitutes a commit. A commit is very much a snapshot of the entire tree. And when you make a new commit, it is again very much a snapshot of the entire tree, based on a single parent commit. So I doubt that you will be able to come up with a workable design to let Git replicate this functionality. > I suppose it may be possible to achieve the same result by treating the > primary repo as the configspec. But I feel like there are some features > config specs support that i do not have using submodules, but might need > down the road. I agree that submodules are unlikely to give you what you want. > I can see that omitting, obscuring, or overwriting parts of a repo would > not play well with the commit id. So I imagine there could be some real > complications trying to add support for the notion of a flexible config > spec. Indeed. The only way I can see that you can _somehow_ combine parts of multiple revisions into one worktree is by transforming those parts into a single commit, quite possibly by scripting the transformation. For example, if you wanted to map, say, `Documentation/technical/` of the tag `v2.34.0` to `tech-specs/` and `compat/poll/` of the tag `v2.30.0` to `poll-emulation/` in a clone of https://github.com/git/git, you could use something like this to create a new branch: ( GIT_INDEX_FILE=.tmp-index && export GIT_INDEX_FILE && git read-tree --prefix=tech-specs/ v2.34.0:Documentation/technical && git read-tree --prefix=poll-emulation/ v2.30.0:compat/poll && tree=$(git write-tree) && commit=$(git commit-tree $tree -p v2.34.0^0 -p v2.30.0) && git branch my-generated-branch $commit ) This would give you a full Git branch that could be checked out and has the mapping. You would have to play similar tricks if you wanted to transport committed changes from that branch back to the originating commit histories. So yes, it is _somewhat_ possible to replicate what you can do with config specs, it is just unlikely to ever offer a good user experience. Ciao, Johannes
