I've started migrating my repos from Codeberg to Worktree.ca; I'll keep the Codeberg repos as mirrors.
Doing this because Worktree is Canadian, and I subscribe; I felt a little bad using a non-profit's infra even though all my stuff there is open source and my CI needs are pretty minor.
EU folks: Codeberg.org is great (Forgejo).
CA folks: Worktree.ca is great (Gitea).
Thanks to a helpful person on CodeBerg, I've finally added a Canadian code repo site to my list: https://about.worktree.ca/
I recently wrote a #blog article about multitasking with #git. Did you already know about the #worktree feature?
https://levelup.gitconnected.com/the-ultimate-guide-to-git-multitasking-58b2970b5b22
#Medium #programming #devops
With #Git 2.25 (Q1 2020), Management of sparsely checked-out working tree has gained a dedicated "sparse-checkout" command.
if you cannot #ssh in, there are trainloads of ways to transport git repositories. You can copy your worktree on some USB stick (including the .git directory), and clone from the stick. Clone the copy, just to get things in a clean fashion again. This might be a PITA, in case your submodules are not accessible from othermachine directly. But there is a solution for this, too
#worktree
https://stackoverflow.com/questions/9572407/git-sparse-checkout-with-exclusion
https://stackoverflow.com/questions/1260748/how-do-i-remove-a-submodule
Odwieczny problem programistów to jak zarządzać kodem na różnych gałęziach, szczególnie w różnych momentach stabilności projektu. Można do tego użyć wcześniej zaplanowanego przepływu gałęziami, ale można też inaczej.
Right, I need a #git #worktree for the current project as I'm having to switch back and forth between two branches to work out why the hell the tests fail on someones development branch and its a pain to have to `git stash` a bunch of debugging on both and switch between them.
Might have to create temproary virtual env's for each but should be considerably less painful
Git. Скачем между ветками как древесные лягушки
Статей на тему много, но, видимо, недостаточно: время от времени слышу от коллег (последние 10 лет, в 4-х разных компаниях): «Не могу пошарить экран с кодом, у меня другая ветка сейчас». «Не хочу переключать ветку, придется запускать кодогенерацию, у меня сбросятся build-файлы, потом это опять пересобирать!» «Стаскивать ветку для просмотра ПР? Это же неудобно, надо "стэшить" изменения, ветку переключать».
@Schwitzd If you find you're doing this often then you can save yourself a lot of `git stash` / `git switch <branch> / `git stash pop` by using Git Worktrees instead.
Article that got me going with them https://medium.com/ngconf/git-worktrees-in-use-f4e516512feb
Now that I'm getting the hang of #git #worktree|s and liking it I'm wondering if I should switch to a #deduplicating FS for all these worktrees. But I still have burn scars from an issue with #btrfs 15 years ago. Where I loaded a buggy #batman_adv version on a shared "server" without knowing much about its code yet. It crashed and killed the btrfs partitions unrepairably. Others in the university #hackerspace were not so happy. But it was the start of many bugfixes in #batman_adv back then. 😅
So I've just discovered git worktrees and it seems like a feature worth using. After playing for a while, a couple of questions:
1) what layout of directories do you prefer? Still trying to find a scheme I like.
2) do you use a bare clone as a base? I see the logic but I've heard it can create some funnies with remote branches
Thanks
Git Worktree is awesome! 🎉
It helps you manage multiple worktrees, which are basically multiple folders attached to the same repository.
You can imagine it a bit like copy pasting your project folder, but with some additional management features.
I am currently using it to manage multiple PRs, which requires its own compiled C++ binary each. With `git-worktree` I do not need to recompile that dependency each time I switch the branch!
Un bellissimo comando che vi aiuterà a gestire i vostri repository git è `git worktree`.
Potete creare effettivi spazi di lavoro che non vanno ad intaccare l albero `.git` principale, dandovi la possibilità di sperimentare senza rischi.
Sperimentate un pochino e divertitevi 🚀
