116
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups (www.tomups.com)
submitted 1 year ago by to c/programming@programming.dev
22 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 13 points 1 year ago (7 children)

yeah, I think these are the main hurdles for me:

  1. Untracked files are not copied

When you create a new worktree, it is created from whatever is comitted, so gitignored or uncomitted files are not copied.

So if you have .env files, you have to copy them over manually. And for dependencies, like for example node_modules, you would have to run npm install again in the new worktree.

Mainly .env files, as they are handcrafted. And:

  1. Editor / IDE complexity.

A few projects I work on are multi-root (using VS Code terminology) and that's already complex enough. Adding worktree directories means adding a level to that, which I'm not bought in. And I don't want a separate workspace for each branch I work on, that just shifts the complexity from git to the IDE / editor.

  • permalink
  • fedilink
  • source
  • hideshow 7 child comments
    •
  • [+] 6 points 1 year ago* (4 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 5 points 1 year ago (3 children)

    Then we have the "it works on my machine" issue. I'm vehemently against symlinks pointing out of the code repository because of that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 9 points 1 year ago (2 children)

    If they're untracked files anyway, that's unavoidable.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 1 year ago (1 child)

    If they're ignored files, setting them up locally won't end up in the repo. If you put a symlink into the repo, fixing that for your setup will register as a change within git, which can cause annoyance and even problems down the line.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 year ago

    Yeah, the untracked files not being copied is also a big reason why I'll typically just switch to a different branch instead.

    I mainly use worktrees when it's useful that untracked files are not copied, like when I need to check out a completely different state of the project, where cached files would need to be invalidated anyways, for example.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 1 year ago

    I've stopped using bare env files on the repo, I'll create an env file that populates values from a secrets manager and check this file info git. Or throw the env file info a parent dir because they're probably user specific anyway.

    Having an env file that needs to exist but isn't checked into source control creates "works on my machine" issues as well, just load them from the environment and provide a programmatic way of setting the environment (or stop pretending they're part of the project and use direnv/Mise to setup the env)

  • permalink
  • fedilink
  • source
  • parent