chore: Added explicit branch versions in .gitmodules

[M3TIOR]

Resolves: N\a

Authors: @M3TIOR

Summary of changes

• Just adds explicit branch versions in the git submodules config file.

Caveats

N\a

On approval

Merge or Wait for me for confirmation.

[vyomfadia]

Nothing wrong with this, but just a question, we checkout specific commits and those commits get checked out every single time without fail - so what would be the reasoning behind using explicit branches?

[M3TIOR]

That's actually not true @beeperdeeper089, if you look at the commit, the original file didn't have specific commits checked out. So each time a new user initially set up the project to work on, it would checkout the HEAD of the main branch for each repository. Luckily most of our dependencies keep their master & main branch as a duplicate of their latest stable release. Our JSON dependency is the only library to deviate from that.

Branch versioning ensures that we always have stable code checked out, and we can use the data for Semantic Version parsing. As an example. When a Semantic Version codebase goes from v3.1.17 to v4.0.0 initial realease, we expect an API change. If all we're looking at is the latest release, we have no way of knowing there was an API change until it causes problems. It's always a good idea build code for the latest stable Major Release Version that was actively supported when the project started. It prevents other projects growth from affecting the active development of the target project.

When git initially does a submodule checkout, it prints out each of the SHA1 Checksums for the commits that were checked out. Perhaps that's you saw that and thought it was the same between devices?

[vyomfadia]

Right, that makes sense about manually forcing a branch, but when I updated the "selected" commit in a submodule - there would be something to stage, you could stage that folder as a file and for example, if I checked out a specific commit, Austin could pull and run git submodule update and it would check out that specific commit - which iirc, we have/had done in for a few submodules in the past.

[M3TIOR]

Odd, I'm using the CLI, are you using the GUI?

[vyomfadia]

I've always used CLI, never used a GUI for Git in my life.

[M3TIOR]

Can you reproduce and show me a few screenshots?

[M3TIOR]

Just so this can be helpful in the future: https://stackoverflow.com/questions/35211547/where-is-a-submodule-commit-number-stored-and-how-do-i-change-it?lq=1

The git submodule update command will make sure the submodules are at the commit stored in the current commit of the parent repository.

Terrible design decision.

Thanks @beeperdeeper089 for this info on Discord.

[vyomfadia]

No problem! What do we want to do about this PR then, it's probably redundant to use explicit things in the submodule file?

[M3TIOR]

It's not redundant, assuming the github commit tracking design was as a backup to maintain reasonable stability without manual tracking. Manual tracking, since it's explicit, means we won't run into issues where different team members accidentally get different versions of submodule code. It's not that hard to manually check on submodule version updates once a month, and we don't really need to do so.

[M3TIOR]

You said it yourself, it would be better if the submodule commit managment happened within the .gitsubmodules file. That's exactly what this does.

[tobyplowy]

Builds and runs as expected. Not like it wouldn't but still worth testing/pointing out =D