1

Problem setup, skip to linebreak for question.

I am working on projectA that has it's own git repo. This projectA has some optional tools in projectB that is its own separate git repo. From what I understand this sounds like a git submodule situation, making projectB a submodule of projectA.

To set this up I use git submodule add projectB. This creates a sub-directory in projectA that acts like a link to projectB, with that information saved in .gitmodule. You need to commit both this file and the "subdirectory". I can continue to develop on projectA without paying any attention to projectB. When I make updates to projectB and push them, I can update projectB within projectA by using git submodule update --remote. This alters the projectB subdirectory in projectA, both by updating the files inside to current version of projectB (not tracked by projectA) and the subdirectory file itself (tracked by projectA).

Now suppose a third user wants to take projectA and make projectC, but doesn't need projectB. They use git clone projectA, they get all of projectA and the .gitmodule and an empty subdirectory for projectB. I would like them to still get .gitmodule so that they have the option in the future, but is it possible so that they don't get the empty subdirectory for projectB?

My question is it possible to hide the subdirectory for a submodule projectB in projectA before the user does a git submodule init > git submodule update?

I'm afraid this isn't possible because that subdirectory is actually a special git file that tells which commit to get of projectB, which I would have thought was saved in .gitmodule. I'm interested if there is a better method for what I want to accomplish or any git hacks.

Novice C
  • 1,344
  • 2
  • 15
  • 27
  • One solution is to make a hidden directory call `.modules` where the submodules all reside (`mkdir .modules; cd .modules; git submodule add projectB`). Then I'll instruct users to make a symlink `ln -s .modules/projectB` in their working directory, having the symlink for a file called `projectB` added to the `.gitignore`. The extra step for those who have to do `git submodule init; git submodule update; ln -s .modules/projectB` anyways shouldn't be a big deal and keeps the project clean for those who don't want the submodule. – Novice C Jul 13 '17 at 05:13

1 Answers1

1

My question is it possible to hide the subdirectory for a submodule projectB in projectA before the user does a git submodule init > git submodule update?

Yes: make a branch for the third user.
Except you need to start that branch from a commit before the one you added the submodule (that way, there is not subdirectory at all).

Then you need to merge your current branch to that branch, without committing: that way, you can delete the .gitmodules and the subfolder (if they keep only the .gitmodules, Git would complain there is no submodule at the designated path).
Commit to complete the merge.

Now, any merge from that branch back to yours will not delete the .gitmodules and the subfolder, because the new branch did not delete those since its creation (hence the importance of starting said branch from a commit before the creation of the submodule.

If later the new user wants to get the submodule, he/she can checkout that file from your branch

git checkout yourBranch -- .gitmodules
git checkout yourBranch -- a/submodule
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Ah clever method thinking big picture. If I'm following the idea correctly, this seems like a patch to do when there is an immediate user who doesn't want the submodules. Otherwise maintaining this separate sans submodule branch seems like a bit of effort. For example if that user wants to pull from the main branch later they'll end up pulling the submodule information correct? So that new branch can in affect only push and not pull. – Novice C Jul 13 '17 at 04:56
  • @NoviceC "For example if that user wants to pull from the main branch later they'll end up pulling the submodule information correct?" Yes, byut again, a `git merge --no-commit` allows for the third user to remove the submodule and `.gitmodules` before committing. – VonC Jul 13 '17 at 04:59
  • I see, this could work well if I actually make the sans submodule the primary master and dev branch. When I need to update the submodule I can checkout the submodule branch doing `git checkout submoduleBranch; git submodule update --remote; git commit; git push`. Otherwise I can just merge results in from the master/dev branch where the actual development will be undergoing without the submodules. Then there is no issue having to fuss with deleting the files every time. – Novice C Jul 13 '17 at 05:11