This issue comes up again and again in posts here and on the web in general. Developers are not always in the position to restructure the repo, particularly when they join an existing project. If Git allows this setup, whether it's the right approach or not, SourceTree should suppot it.

Well, git kinda lets you do what you want - but if the branch says that the submodule state should be 'X', but it's not possible to work with that state realistically even if you want the other contents of the branch, that says to me the branches should be separate.

Leaving the fact that it's a submodule out of it, it's akin to having a folder of source that's effectively not in sync with the rest of the code, or unstable when the rest is stable. Most people wouldn't hesitate to create a separate branch for that kind of work, and it's really no different if that work is in a submodule instead - it's just that the branch simply tracks the submodule commit instead of the source files themselves.

HTH

Thanks for the reply.

OK, so it seems to me the workflow here is a not that git conform it should be. I guess it is not possible for me to change it as a freelancer but i will discuss it with my colleagues.

Kind regards
Stefan

I'm not sure I understand - are you making your own changes to the submodule too? If so these should show up as a conflict.

If you mean that it's only the customer who is making changes to the submodule, and those are getting pulled in, that's because they're committing & pushing changes to the submodule commit that is tracked in the branch you're working on, in which case SourceTree should be updating your local copy, because that's what the branch says should be the case. If the customer is pushing unstable changes to the submodule then they should probably be using another branch in the parent repository to update the commit that it tracks, rather than pushing the tracking change to a shared, presumed stable, branch.

If you check out a different submodule commit all the time, or if SourceTree didn't update the submodule for you, this would show up constantly as a local change (which presumably you'd just manually avoid committing). I could add an option not to update the submodules to the correct state, but this just seems a bit of a band-aid for what could be handled more appropriately upstream with a different branch for tracking those unstable changes in the submodule.