Настолько давно не пользовался сабмодулями в Git, что вчера добавив сабмодуль на одной машине уже сегодня на другой сидел и не мог сразу понять а чего проект не собирается-то.
А вы когда последний раз использовали submodules?
Current state Intelligence Core:
#ETLpipeline : Validated. 5,458 rows ingested in 49s.
#submodules : scraper-base-kit & market-intelligence-connector fully integrated.
#Data Logic: live Z-Score / IQR outlier detection for analysis.
modular architecture self-hosted on #ArchLinux
#BruteForceEngineering #DevAgainstTheMachine #DataScience #Python #Grit #gritlab #AnarchyInTheShell
Not gonna lie, a few years ago when I eared @robinm asking for a built-in plugin manager in #vim / #nvim, I was not convinced.
Why? Because I thought it was already the case. `pack/{opt,start}` has been around for quite a while now and I used #git #submodules to have a portable configuration.
Since then, I've used various plugins manager. They're handy but don't offer much more than the built-in.
And now, back to sugar-coated basics: https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack.
I now agree with @robinm.
Managing Git Submodules just got way less annoying 🧩
Submodules are powerful, but managing them usually involves a lot of clicking around or switching views.
SmartGit 26.1 Preview puts an end to that 🎉
You can now handle everything right from the Standard Window. Just right-click a submodule to:
✨ Initialize or Deactivate
🔄 Synchronize
🛑 Unregister or Reset
No more menu hunting. Just right-click and get it done.
I use #Git. A feature of Git I leverage heavily is #Worktree. I usually have at least four around at a time. For small tasks, sure, a simple branch and then switch back, but bigger things: a worktree.
Making a worktree is actually annoying for me: not just the upfront decisions about branches and start points and where to put the new directory (and also immediately `cd`ing there: but getting all the #submodules (submodules suck by the way), hooking up `.envrc` if you use #Direnv (and you should be), which should then set up your virtual environment and path and stuff. Clone isn’t quite as bad but has some of the same problems.
I do this so often, I wrote a script. It might be useful to others with this workflow. It’s opinionated, and therefore I could really use some feedback! What did I do right? What did I do that’s only right for me? What is totally missing?
The script is stand-alone, though you do need #UV. (You don’t even need Python! `uv` will transparently get you everything!) Just download this one Python file, and get it on your `$PATH`. If you want the additional `cd` behavior, then add the shell function, too as described in the `README`. Everything is tested. The tests are right there, too.
https://github.com/wolf/dotfiles/blob/main/git/dot-config/git/bin/make-worktree.py
The `README.md` is right next to it.
I **do** see one thing I’m missing: I need to provide a way to automatically copy in your custom stuff. I’ll add that today.
Your main #quarto website repo shouldn't be a storage unit for every plot you've ever made 📦
#git #submodules: Give your figures their own space, keep your repo fast
People please learn to use #git #submodules for your dependencies. This is the only way that allows you to vendor the exact commit/version into your app while also allowing you to easily update them regardless of where it is checked out. Especially for CI/CD this allows e.g. access token to just magically work. Regardless of how deeply nested they are.
(also don't split a monolith across multiple repositories using it, submodules *only* excel for managing standalone dependencies)
So what's the smoothest way these days to integrate localisation repositories into your git repo?
As a background: our localisation needs to live in a separate git repo that is monitored and also updated with new translations by pootle (a translation tool) but we also want to be able to pull out the generated PO files as well as push local updates (and new texts) from within the containing project repo the localisations belong to. So merges / rebates are kinda required.
Git submodules are the worst case here as you can't really commit / push local updates to the translations back to the localisation repo without making a separate checkout, doing your changes there, then pushing to your remote and finally updating the reference for your local submodule and pulling again.
Git subtrees sounded like a good idea but they way they're implemented makes them nasty to use as well.. they tend to break if you work with pull --rebase in the containing repo and merge conflicts in the sub tree can't be resolved with a sub tree-rebase either.
In the past I used to have the localisation as a full git checkout in a sub directory of the containing project and maintained it using a few CMake scripts but I had hoped there's be something smoother by now.
#git #submodules #subtree #localisation #i18 #workflows #question #SofwareDevelopment #boostswelcome
Alexey Skobkin
Dev_against_the_machine
Paco Velobs
SmartGit
Wolf
ᴅʀ. ᴍᴏᴡɪɴᴄᴋᴇʟ'ꜱ
James Balamuta
Klaus Frank
Heals 