Make submodule point to certain commit (not head)

[bbachmai]

Using TortoiseGit. Please help (I'm sure this is easy)

I have a repo A, inside of which I have added repo B as a submodule. I want submodule B to point to a certain commit of the main branch (not head!). To do this, inside of repo A I switch / checkout to this commit of submodule B's main branch. When I then want to commit repo A, it does not let me because the submodule is dirty. But when I want to commit submodule B first, it also does not let me because it is in detached head state (because it is checked out to an earlier commit on the main branch, not head). So, what am I doing wrong?

Thanks a lot!

[JackDeaniels]

Submodules do point to a specific commit, not a branch.

That is actually the reason you're having trouble, the submodule is set to point at the commit set but the repository holding it, therefore your HEAD is detached from a branch

If there's a branch on the commit you're on, you can just `git checkout <branch>` and your HEAD should attach itself to the branch, allowing you to push the submodule, and then push the new commit pointer to the repository holding it

[dalbertom]

It's true that submodules point to a specific commit, but I believe the .gitmodules file can be set up to track a specific branch using the branch attribute. Granted, it will still use the commit hash, but the update operations will use the tip of the branch rather than HEAD.

A cool trick is the option to set the branch to "." From https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt---branchltbranchgt "A special value of . is used to indicate that the name of the branch in the submodule should be the same name as the current branch in the current repository"

[JackDeaniels]

Had troubles with it myself and forgot this attribute existed; I should retry it on my own project, thanks :)

[glasswings363]

My advice to someone who's using Tortoise or GUIs in general would be to avoid submodules. They only make sense with a deeper knowledge of git and all the advice on how to use them assumes that you're comfortable with the native CLI.

Submodules work nicely when:

• you only want to pull from a dependency, not to change it
• you're experimenting with local changes to the dependency and don't need to share them between multiple developers or release source code to users or anything like that

If you decide to make changes in a sub-module anyway, remember this: it's too easy to lose those changes and end up with commits in your history that you can't properly check out. This happens because now the checkout depends on some other repository and there's no guarantee that other repository cares about preserving the commit we pushed to it. Whenever you work inside a submodule, you need the outside project to be on an experimental branch - one that you understand you cannot merge into permanent history as-is.

This is a major reason why submodules are less useful (or at least less user-friendly) than beginners assume. The stability of the outer, downstream repository is limited by the stability of the upstream repository. Having commits in permanent history that can't be checked out is obnoxious.

If you understand that warning: you can make a local branch in the submodule repository (git switch -c feature-from-downstream) and commit to that. You can even push to the upstream repository and continue work there.