3 ms·
Yes I had a similar experience. the thing that tripped me up with git worktrees, which is maybe obvious in retrospect, is that they don’t include things that ar
by pjm331 1y ago
Yes I had a similar experience. the thing that tripped me up with git worktrees, which is maybe obvious in retrospect, is that they don’t include things that are not tracked by git - e.g. .env.development.local
So starting a new worktree requires additional setup and isn’t as simple as just checking out a new branch
- js2 1y agoCould you group the main repo and its worktrees under a common parent directory that contains your .env.development.local?
- pjm331 1y agoAh that’s a good idea I’ll have to try that out
- Charlieholtz 1y agoSorry about that! We’re working on making this more intuitive. Internally our workflow looks like this: - we have a script that sets up a repo — copies env variables, runs pnpm i, inits a db, etc - we have a field in the repo settings called “setup script.” every time you make a new workspace, that script runs Hopefully will be much improved over the next week or two!
- irskep 1y agoI'm working on a little wrapper that solves this problem. I have similar needs with .env files, and in my case running 'uv sync' to install dependencies. I linked it elsewhere in this thread so I won't repeat the URL (autowt). It's definitely possible to make this workflow effective with some scripting.
- rafaelmn 1y agoBut that is also the selling point of worktrees - I have them for multiple features I am working on, I just spin up services that I need for each feature separately, like databases, etc. How else are you going to isolate migrations, configuration changes, etc.