Working with subtrees in a second working copy
Suppose we have two developers. One developer added a subtree to the “main” git repository at foo/bar/ path (foo/ is a normal directory and foo/bar/ now is connected as a subtree to a separate “subtree” repository). The second developer pulled changes and got foo/bar/. However at his working copy foo/bar/ is not a subtree to git, it is just a directory in the main repository.
Now the second developer got the task to switch that subtree to a newer tag in the subtree repository. He thinks he can pull from the subtree repository using
git subtree pull but than he needs to add a substree first. But
git subtree add in his working copy does not work because the directory already exist. In his working copy this directory does not look like a subtree to git.
- Include utility repository in main project repository and allow customization
- Detach (move) subdirectory into separate Git repository
- git-subtree push --squash needs a long time, and it is getting longer over time with more commits
- Git detects changed files that are actually byte-identical
- How to integrate build output from one git repo into another
- Git subtree merge strategy or subtree command?
- How can the second developer tell git that foo/bar/ is actually a subtree?
- How can he checkout a tag for this subtree?
2 Solutions collect form web for “Working with subtrees in a second working copy”
I don’t believe subtree has any built-in method to let the second developer know a subdirectory is actually a git subtree. The best way to indicate that may be with a file in the root of the subtree (which is not ideal I’ll admit).
The second developer in your example, shouldn’t have to do a
git subtree add though. They should only have to do a pull followed by a push (again, they’ll need some other way of knowing where it all came from).
To update the subtree, the second developer would:
(NOTE: I’m new to subtree, so take this for what it’s worth)
- Make their changes as usual
- Commit their changes to the ‘main’ repository
- Push their changes to the ‘main’ repository
- Do a pull from the subtree:
git subtree pull --prefix=bar ../bar.git master
- Do a push to get their changes in the subtree:
git subtree push --prefix=bar ../bar.git master
The whole point of subtrees (in contrast to submodules) is that they do not look like repositories and do not need any configuration files. git-subtree encodes all required information for subsequent merges in the initial merge commit, using a “git-subtree-” prefix, so there really is no difference between the two developers’ working copies in your example. Both will equally be able to
git subtree pull ....
If you want to have explicit (i.e. recognizable) sub-repositories that can be easily updated from upstream, use