0

Situation:

We have a project which consists of many submodules stored in app/modules folder. All submodules are independent and each group of users (developers) should work only with a specific subset of the submodules. This can be easily achieved by executing git submodule update --remote --merge app/modules/SomeModule for specific submodules only (i.e. don't init/update all available submodules).

Question 1:

If some user does not need access to certain submodules, empty submodule folder will still exists. Is it possible to ensure that empty submodule folders don't exist by default and are created on request only (e.g. after init/update) ?

Question 2:

More general question about submodules - is it really needed to commit submodule changes into the main project? I know it is used to store the submodule's commit hash to the main project, because it is not stored in the .gitmodules file. But our submodules are tracked branches git submodule add -b BranchName ... and developers always pull the latest submodule version using git submodule update --remote --merge, is commiting it to the main project needed ? The main sense is that the submodules and main project are separated, so there seems to be no reason why the main project should know about submodule version/commit/history.

bigmuscle
  • 419
  • 1
  • 6
  • 16
  • Q2: [Git 1.8.2 added the possibility to track branches](https://stackoverflow.com/a/15782629/7976758). – phd Mar 16 '18 at 12:02
  • Sure, I know it. But do I understand correctly that if I use this "possibility to track branches" using -b and --remote arguments, I don't need to commit the submodule state into the main project? – bigmuscle Mar 17 '18 at 10:17

1 Answers1

0

Tracking the SHA of the submodule is really the whole point of submodules. So you can check out a specific version / branch of the parent and get the corresponding versions of the children.
If you don't need this, it would be a lot easier to not use submodules in the first place.
Just add all directories you currently have as submodules in the .gitignore and every developer can clone the repositories he needs with normal git clone.
This would solve both your problems.

lukas-reineke
  • 3,132
  • 2
  • 18
  • 26
  • Thank you for your opinion. Using .gitignore+clone seems like an interesting idea. But we decided to use the submodules, because everything is managed by the main project - it contains the list of submodules, their branches and their remote URL and developers don't need to care about anything. They just select the requested submodules using the standard GIT tools (regardless their GIT client, OS etc.). When using .gitignore+clone, any module would behave just like completely separate repository. All users would need to know the remote URL and clone all requsted modules one by one. – bigmuscle Mar 17 '18 at 10:21
  • True, every developer would need to manage them himself. There is an option to stop git from tracking files, which works for submodules as well. `git update-index --assume-unchanged path/to/module`, but this is client site. So every developer would need to do this for every submodule. – lukas-reineke Mar 17 '18 at 16:43