Submodules bit me more than once, because they break the assumption that once you check the top level repository out everything is in the state you checked out.
I understand why nested repos isn't a straightforward problem to solve, but I feel this could be solved better, especially in the UI.
> because they break the assumption that once you check the top level repository out everything is in the state you checked out.
This assumption, at first, is still valid as the parent repository stores the hash of the submodule. The checkout in this case will change the commit of the submodule just like it changes the blob of a file (using --recurse-submodules you also update the submodule directory).
Of course! I mean, I think submodules should be one of the last options to be considered. I wrote this article because I didn't understand entirely them and the information that I found on the internet were too shallow...
3 comments
[ 2.6 ms ] story [ 20.6 ms ] threadI understand why nested repos isn't a straightforward problem to solve, but I feel this could be solved better, especially in the UI.
This assumption, at first, is still valid as the parent repository stores the hash of the submodule. The checkout in this case will change the commit of the submodule just like it changes the blob of a file (using --recurse-submodules you also update the submodule directory).
But, yeah, it still depends on the existence of the commits on the submodule repo, which may not exist after performing a git push -f or a squash merge (that last case I discussed here: https://lucasoshiro.github.io/posts-en/2024-06-27-squash-sub...)
> but I feel this could be solved better
Of course! I mean, I think submodules should be one of the last options to be considered. I wrote this article because I didn't understand entirely them and the information that I found on the internet were too shallow...