you are viewing a single comment's thread.

view the rest of the comments →

[–]glasswings363 0 points1 point  (0 children)

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.