Hacker News Reader

Comment by therealmarv | Hacker News Reader

Maybe I'm stubborn, but even in the age of AI, I still use multiple git clones/directories of the same project, e.g.:

  ~/dev/projectx
  ~/dev/projectx2
  ~/dev/projectx3
  ~/dev/projectx4

very rarely use more than 4–5 per project. Maybe I'm just avoiding wrapping my head around worktrees and actually trying them out.

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.

View on HN

this is basically what worktrees do, though? except git 'knows' about all the associated branches, so you don't have to deal with pushing/pulling in order to merge xyz branch, etc.

The main issue with worktrees is that you can't have the same branch opened in multiple worktrees which makes many things harder than the ought to be. I don't really understand why we need that limitation, otherwise the tooling is good enough.

JJ workspaces don't have that limitation. They do limit you to not having the same working copy commit opened in more than one location, but that's not particularly restrictive with JJ since you're probably squashing changes from the working copy into a permanent commit anyway.

The article said that a "limitation" of worktrees is that a branch can only be checked out in one worktree at a time- however, this seems like a feature, because if you could have several worktrees each with their own overlapping sets of branches then surely that would be equivalent to many git clones?

But yes, personally, in my ignorance, I shamelessly git clone the same repo many times.

I'm also stubborn. I clone multiple copies of the repo. I'm currently at two at my job right now, because I was trying to vibe-code an E2E test suite.

I'm probably missing something that people see as a huge advantage of having multiple streams of work large enough to require a long-running branch. I just finish working on the current branch and then switching to another branch. If work can't be accomplished and merged into `main` within a small amount of time, I'm almost certainly doing something wrong.

Reply on news.ycombinator.com