#submodules — Public Fediverse posts

Настолько давно не пользовался сабмодулями в Git, что вчера добавив сабмодуль на одной машине уже сегодня на другой сидел и не мог сразу понять а чего проект не собирается-то.

А вы когда последний раз использовали submodules?

#dev #Git #submodules #log #vote #survey

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

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

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

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.

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.

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.

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.

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.

@justine You should definitively look into #git #submodules.
I did what you're doing a while back. And having a repo of repos instead of a directory of repos is a blessing.
Need to update : `git submodule update`.
No loop, no bash, no "involved" logic, just use what's already there instead of reinventing the wheel.
@mms

My new article on Hugo modules vs. Git submodules is LIVE! 🚀 Learn how to streamline your website management. Read now: https://drmo.site/fnJbML #Hugo #Git #Submodules

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

https://blog.thecoatlessprofessor.com/programming/quarto/stop-bloating-your-main-quarto-website-repository-with-generated-figure-files/

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

A new post on my blog:

Nested repos

I've once again been thinking about git submodules and how I might be able to use them when making games. My requirement is to have my open source game, but potentially use commercial assets inside without exposing those assets in a public git repo.

I also took a side quest to look at Mercurial, since the "best" source control systems for game development are stupidly expensive. Mercur

https://taffer.ca/nested-repos/

#GameDev #git #submodules

I wrote a blog post on why I use #git #submodules despite the fact that they're awful :)

As I say in the article I welcome ideas on how to do this differently. My implentation isn't perfect but it does what I need for now!

https://www.feoh.org/posts/git-submodules-are-awful-but-occasionally-necessary

#nix flakes and #submodules—a new source of pain. ffs.

Somewhere in the world @jacobsee has probably felt a disturbance in the force and is probably laughing due to numerous occasions of me having a meltdown over projects that have used #submodules.