I always like good recommendations, but that does bring up the question. If you can't safely git pull the SDK and rely on it properly fast-forwarding and correctly orienting HEAD - doesn't that turn the entire idea behind git on its head?My recommendation is to not do that, using 'git pull' to upgrade. Instead rename as 'pico-sdk-2.1.1' or whatever you had, or even delete it, and then 'git clone' the latest.
The entire purpose git has in life is to be able to track local and remote branches and synchronize the state of any one branch to its current HEAD pointer. I've never heard the recommendation of delete, move and then clone again. So long as you have not modified your local repository or have outstanding commits that you need to stash or throw away, what benefit is there to deleting and re-cloning instead of just pulling?
At least in my experience, first cloning the SDK years ago, git does what it was designed to do without any issues. Maybe that recommendation is in the docs for those who are unfamiliar with git to avoid issues where the user has someway altered the local copy of the repo and then runs into problems trying execute a pull? That would be the only conceivable reason I could think of to necessitate deleting and re-cloning. You do have to be mindful when submodules are replaced, but that's not a reason to delete everything and start over?
I will keep that recommendation in mind if I ever get my local copy out of sync to the point I can't fix it. But for the past few years I've been able to switch between master and develop as needed and pull updates and git has been flawless keeping the SDK in sync and up to date from the first, and only, time I cloned it.
Are there other specific reasons for the pico-sdk that I'm just ignorant about that prevents the seamless use of git in this manner?
I guess the difference is I used the Appendix C Manual Toolchain Setup -- when that was the only setup offered. I set the build environment up on Archlinux and openSUSE (and on windows based on MSys2) so it is more of a manual setup. In each of the cases and in Appendix C, there isn't a recommendation to delete and re-clone. I also do not use the vscode extension (the "vscode" extension and then 8 others it unnecessarily pulls in). The inclusion of npm in that software stack is a deal-breaker from a security standpoint. (most recently [this past week] the widely included npm "is" package was compromised).
Now I can easily see that extension getting out of sync, but that wouldn't be a direct result of git. If you know what the reason behind the recommendation? I'm curious at this point and can't clearly see "what part of what" would be driving the recommendation to delete and re-clone rather than pull?
Statistics: Posted by drankinatty — Thu Jul 31, 2025 6:28 pm