Checkout branch with different submodules is not working

[redihokuto]

Pretend you have a project with 3 submodules: bee, zebra, lion
Create a new branch alpha and checkout it.
Remove zebra by running
git submodule deinit zebra
That will empty the zebra directory (but not the directory itself) and remove the related section from .git/config.
To actually drop the entire submodule complete the operation with
git rm zebra
It wiil delete the directory zebra and modify .gitmodules
Now the submodule is gone. Commit the modifications.
To properly checkout master you should, essentially
git submodule deinit .
git checkout master
git submodule update --init --recursive

To go back to alpha, again
git submodule deinit .
git checkout alpha
git submodule update --init --recursive

If you don't run the first command deinit, alpha will contain zebra while it shouldn't!

[KindDragon]

I think you describe Git issue, not GitExt

[redihokuto]

I don't think so.
I feel Git submodule was designed to be somehow detached from the rest.
That's why we need to git submodule update --init --recurse after a checkout.
Otherwise, if they were fully integrated, the simple git checkout should do the entire process.
Similarly of what is done after the checkout, we have to run git submodule deinit . before the checkout.
Look at them as prolog and epilog around the checkout operation.

[KindDragon]

git submodule deinit .
git submodule update --init --recursive

Calling it at each checkout it's too time consuming

[redihokuto]

Yes, it's time consuming. Nevertheless it is the only way to grant project consistency.
Maybe it is possible to reduce the operations to only few submodules, but you need to know how the 2 branches differ from each other before the checkout.

I think having consistent checkout has higher priority than operation time

[OAkyildiz]

I am running to a similar issue/feature need. Only thing that seems to be shared across branches is the config file. If [branch] tags had the option similar to

submodules="all" | -zebra | bee, lion

and that allowed to leave the submodule info in the config file but only process it if the active branch lists/includes it. Speaking very hypothetically here, what about copying the config file into the repo (so each branch has it's own version) and you soft-link that to the original file (had to be done after every clone), would that work?

[GintasS]

Abandoning this because of age and lack of discussion.

[gerhardol]

GE supports checking out submodules when checking out commits.
(or run manually as a user script)

[andry81]

I feel Git submodule was designed to be somehow detached from the rest.

More over, there is no need to .gitmodules file. The git working copy config can contain the reference to the remote url or the declaration of the current working copy as a submodule:
https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt-init--ltpathgt82308203

Optional <path> arguments limit which submodules will be initialized. If no path is specified and submodule.active has been configured, submodules configured to be active will be initialized, otherwise all submodules are initialized.

.git/config example:

[submodule]
	active = .

So the subset of commands git submodule ... may won't work as expected because the git config would be out of the target working copy - in a nested working copy.

[vbjay]

The .gitmodules file does provide a purpose. It is how the sync command works. https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt-sync--recursive--ltpathgt82308203

[andry81]

The .gitmodules file does provide a purpose. It is how the sync command works. git-scm.com/docs/git-submodule#Documentation/git-submodule.txt-sync--recursive--ltpathgt82308203

That is not complete information, there is another ways exists: #10642

[vbjay]

.gitmodules is a template source for urls and is modified when you add/alter submodules. It is included in the repo so when you push to a remote and someone pulls down they get the same submodule info. Think of .gitmodules as the original and config as your working copy definition. sync puts you back to same as original(.gitmodules). So please stop compaining about a standard and well known git feature in this repo and instead if you have desires to aler git itself... go there.

[vbjay]

On the active note. That will just work because git will understand it. Since we just call submodule update --init.. So if you configured active.... That command would respect the active config rule mentioned.

Active submodule info

https://git-scm.com/docs/gitsubmodules#_active_submodules

[andry81]

So please stop compaining about a standard and well known git feature in this repo and instead if you have desires to aler git itself... go there.

I am not. This is just a fact. The git submodule summary detects submodule w/o .gitmodules.

[vbjay]

So show us the problem in GE. Provide a sample repo we can pull and show what you expect vs what you get. I would stop in this issue and post a clear and well defined issue. I see you created #10642

So post the details and what you expect vs what you get to help us see the issue in that issue.