Reputation: 3283
I have a Git repository with the following structure:
src/
.git/
Api/
Web/
I want to clone another repository to the Web directory and pulling new changes from a remote to Web later from time to time. But I also want to modify the files under /Web
and push every change that I made to my main remote.
I don't want to push anything to the Web's remote, just to the main one.
If I pull the changes from the Web remote, I'd like to see the changes that I pulled in the main history.
Can I use git submodules in this scenario?
The docs says that "The other repository has its own history, which does not interfere with the history of the current repository."
that's why I'm hesitating, probably this is cannot be done with submodules...?
Upvotes: 1
Views: 118
Reputation: 60255
That will work. Git treats everything in directories that have tracked content underneath as part of the existing worktree; it only stops at .git
-containing-directory boundaries when it's scanning currently-_un_tracked directories.
The thing is, you're not using the nested repository as a submodule at that point -- you're committing actual content to your main repository, not just the id for the currently-checked-out tip in the nested one. Don't use the submodule command at all, that'll contradict everything else you're telling git about the content.
You'll have to add any changed content to your main repository just as you would for any other changes. You could additionally add it to the nested repository and track it there as well.
and push every change that I made
Git doesn't store changes, it stores snapshots. It analyzes the stored snapshots to detect and work with changes on demand.
Unless you've got the results of a very concrete cost-benefit analysis backing the decision, don't do this.
Upvotes: 1