Advertisement
Advertisement
β‘ Community Insights
Discussion Sentiment
50% Positive
Analyzed from 598 words in the discussion.
Trending Topics
#worktrees#git#clones#more#project#dev#multiple#directory#worktree#checkout
Discussion Sentiment
Analyzed from 598 words in the discussion.
Trending Topics
Discussion (15 Comments)Read Original on HackerNews
To solve some of the ergonomics issues (command verbosity, manual commands to copy over .env files and install dependencies), I wrote autowt, which is a lightweight but powerful worktree manager: https://steveasleep.com/autowt/
Once I dialed in the cli experience, I basically stopped typing 'git checkout <branch>' to change tasks, because it's easier to ignore working directory state when flipping between tasks.
Benefits: These clones act as semi-permanent directories:
- Helps with caching for heavy Docker usage (think of repeated parallel unit, e2e tests)
- I've color-coded my terminal tabs for each clone so I can instantly tell where I am at a glance (kinda like tab groups just with colors)
Maybe if for some reason I need double digits clones of a project I will be more forced to use git worktrees because then it will be annoying to remember in which directory a branch clone lives.
https://fossil-scm.org/home/doc/trunk/www/gitusers.md
I use it's config to copy in some non-repo config and then hooks to start an agent doing analysis.
I already know a place I want to use this.
I'm not really sure what worktrees adds on top of that.
If you're setting up long-lived checkouts that you reuse, it doesn't help much (except perhaps saving space or bandwidth) vs multiple clones and some once up-front reconfiguration. On the other hand, if you want something more temporary - and perhaps based on your current HEAD without having to hunt down a commit id to feed a subsequent git clone / git checkout command - worktrees save you some boilerplate (re)configuration.