this post was submitted on 05 Apr 2024
127 points (96.4% liked)
Programming
17509 readers
7 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Why using a worktree? I will simply commit my WIP modifications on the dev branch.
Switch branch to work on the bugfix. And when Im finished I move back to the development branch? Why is this worse than doing this worktree stuff?
I'm a C++ dev, I have one checkout of the main repo and 3 worktrees. Switching branches can be expensive because of recompiles, so to do e.g. quick fixes I'll use worktree 1 where I typically don't even compile the code, just make the fix and push it to the CI system. Worktrees 2 and 3 I keep at older releases so I can immediately fire up development and one of those releases side by side and compare results as well as the code.
The cool thing about worktrees instead of multiple checkouts is that you only have one .git folder, so less disk space. But more importantly local branches (well everything actually) are shared, so you can create a local branch in the main checkout, and later come back to it in a worktree. You also don't need fetching/... in the worktrees, as they share the same .git folder.
Only thing that I found virtually impossible to work with is worktree + submodules.
Huh, you know what, maybe I'll give something like that a try. In the past I've tried doing one worktree per branch, but it was a pretty big hassle since I'd have to copy over a bunch of files every time (stuff sitting in the directory but not version-controlled). Yeah it can be automated, but it didn't seem worth it. But a persistent set of work trees that I can use to parallelize when needed sounds pretty good.
thanks for elaborating. will give it a try :)
Ah man, I'm with a project that already uses a poly repo setup and am starting an integration repo using submodules to coordinate the Dev environment and unify with CI/CD. Sub modules have been great for introspection and and versioning, rather than relying on some opaque configuration file to check out all the different poly repos at build time. I can click the the sub module links on GitHub and redirect right to the reference commit, while many IDEs can also already associate the respective git tag for each sub module when opening from the super project.
I was kind of bummed to hear that working trees didn't have full support with some modules. I haven't used working trees with this super project yet, but what did you find about its incompatibility with some modules? Are there certain porcelain commands just not supported, or certain behaviors don't work as expected? Have you tried the global git config to enable recursive over sub modules by default?
I found basic functioning of worktrees to fail with submodules. The worktree doesn't know about submodules, and again and again messes up the links to it. Basic pulling, switching branches, ..., all of this frequently fails to work because the link to the submodule is broken. I ended up creating the submodules as worktrees of a separate checkout of the submodule repo, and recreating these submodule worktrees over and over. I pretty much stopped using worktrees at that point.
Nope, fingers crossed it helps for you ;) Unrelated to worktrees but: in the end I like submodules in theory but found them to be absolutely terrible in practice, that's without even factoring in the worktrees. So we went back to a monorepo.