I have a git repository containing several linked projects like

|-- configs
|   |-- A.py
|   `-- B.py
|-- datasets
|   |-- a.py
|   |-- b.py
|   `-- c.py
|-- models
|   |-- x.py
|   `-- y.py
`-- projects
    |-- A.py
    |-- B.py
    `-- common.py

I would like to publish a subset of those files with a new remote. From reading the documentation, it's seems not possible. What alternative would you suggest? I'm thinking of:

• copy-pasting to a new repository (but if code is updated on one side, I won't benefit from the changes on the other side
• pushing the whole repository to the new remote (but I'm not sure I want to share everything)
• Restructuring repo and use submodules or git subtree (but it gets complicated for the common files, that would mean creating 3 repositories (one for each project one for common things, which is messy to maintain, especially for very few files)

Any advice on how to address this problem?

CodePudding user response：

Git manages commits. Each commit associates a file tree, containing the list of all files. This file tree is part of the commit hash, and a key part to the integrity of the repository. As a result, Git cannot push a subset of files, as it would mean having to change commits. Git subtree is a common tool to maintain two history lines, one for external use that can be restricted to a subset of directories, and the internal one.

You have various options, as you mentioned. Copying, which defies the use of the source control system, pushing the whole repository or using either git submodules or git subtrees to produce a smaller repository that you can share. I can recommend git subtree as it is quite easy to manage and can easily merge files back from a changed upstream.