4 ms·

I use worktrees very rarely. For instance, if I'm trying to figure out some very hard to reproduce bug that disappeared between one revision and another and I n

I use worktrees very rarely. For instance, if I'm trying to figure out some very hard to reproduce bug that disappeared between one revision and another and I need to examine the code. I can't just bisect if the feature set or interfaces are different so I need both versions of the code. Sometimes I cherry-pick around to restore some similarity. But for this two-patch flow, I'm just going to use two branches.

frfl 3y ago
Being able to explore code from another revision in your regular editor side by side with your other branch (two editor instances) is a big plus of worktrees. Maybe it wouldn't work if you use some heavyweight editor like Visual Studio or Eclipse or if your project is massive and IDE intelligence features take up a lot of RAM, but for lightweight editors, small-medium projects it works great. I personally use it all the time on longer lived projects. Stashing/unstashing is fine, but I like really like the flexibility of just being able to switch over to another branch to fix something, review a PR, or anything else with zero mental overhead of keeping track of stashed work.
- renewiltord 3y ago
  I used to use it myself. Not too much of problem. I just didn't use it enough to warrant use. Was quite straightforward to just switch up. But I shall try it again and see.
- chatmasta 3y ago
  The thing that annoys me about worktrees is that you can't have two checked out to the same commit at the same time [0], which can be inconvenient when I forget about one that I had open a few days ago. This also breaks the feeling of isolation, since the issue doesn't exist if I do a fresh `git clone` to another directory, so it begs the question of what fragility is present in worktrees that isn't in a fresh clone. In other words, I wouldn't feel safe doing weird Git operations in a worktree, so why use one in the first place? If I want a true throwaway repo, I'll just re-clone in another directory (and make sure to remove the remote, to be extra safe in case I accidentally push). Also, git worktree requires me to make a new directory anyway! So why would I not just put a fresh clone in there? To save a few megabytes of the .git index? [0] https://stackoverflow.com/a/39668520 https://stackoverflow.com/a/39668520
  - frfl 3y ago
    You can make a temporary branch if you want an identical copy of a revision. For example, `git checkout feature-x` (on worktree 1), then `git checkout -b feature-x-temp feature-x` (on worktree 2). I've never had any issues with worktrees after heavy and extensive worktree usage since 2017. I use it regularly on big projects. The only time I had an issue with git was actually on a small non-worktree repo after 10 years of using git. The .git/ metadata got corrupted somehow, never understood why or how. When you have a worktree based workflow, you're getting the benefit of a single .git/ database managing them. Whereas if you have multiple standalone clones, you have to manually keep them up to date. With worktrees doing a `git fetch` will ensure all worktrees are able to do git operations on the most update to date git data. Whereas separate clones means you need to do N git fetches. Saving a few megabytes literally doesn't matter. Your project dependencies will likely use up tens if not hundreds of megabytes when you install them (pip packages, node modules, etc). Disk space is never really an issue anymore is it? Disks are hundreds of GBs now even on low end machines. I probably have multiple GBs of redundant disk usage because of my worktrees, but the convenience is well worth it IMO.
  - jrockway 3y ago
    I find this very annoying. I don't know if this is the right thing or not, but my workflow for starting new work is "git checkout master; git pull; git checkout -b new_work". This is all fun and games until you have a worktree that's sitting at master. Now you have to figure out where that is, chdir there, and update that branch from the remote. It's actually extremely annoying. Maybe there is "git update master from remote and throw away my local changes because if i committed something there that was a mistake". But probably not, sadly, because technically the "git pull" operation to pull origin/master into the local tracking branch master updates the working copy where master is checked out, and that's what worktree is trying to avoid (changing a directory you're not in). I guess "git pull; git checkout -b new_branch remotes/origin/master" is what I should write, but that's more bytes to type.
    - wiredfool 3y ago
      git fetch origin git checkout -b new_work origin/master Git pull is essentially git fetch + merge. You don't have to update your local master branch to check out a new branch based on it.
azemetre 3y ago
I use to work at a company whose product had multiple versions of Java over its existence (literally think from Java 5 to Java 18), depending on the major product support versions (yes we had clients still on 1.0 system from the early 2000s, they were mostly regional banks). Worktrees made working on that monolith easier to do my types of tasks (updating tests that were specific to the UI team I was on, also the only person willing to touch java code). It sounds kinda backwards, but if you have to support multiple versions of a product that still brings in hundreds of millions in revenue it's nice to use git worktree to basically check out different versions of your product in time.

frfl 3y ago

Being able to explore code from another revision in your regular editor side by side with your other branch (two editor instances) is a big plus of worktrees. Maybe it wouldn't work if you use some heavyweight editor like Visual Studio or Eclipse or if your project is massive and IDE intelligence features take up a lot of RAM, but for lightweight editors, small-medium projects it works great. I personally use it all the time on longer lived projects. Stashing/unstashing is fine, but I like really like the flexibility of just being able to switch over to another branch to fix something, review a PR, or anything else with zero mental overhead of keeping track of stashed work.

renewiltord 3y ago
I used to use it myself. Not too much of problem. I just didn't use it enough to warrant use. Was quite straightforward to just switch up. But I shall try it again and see.
chatmasta 3y ago
The thing that annoys me about worktrees is that you can't have two checked out to the same commit at the same time [0], which can be inconvenient when I forget about one that I had open a few days ago. This also breaks the feeling of isolation, since the issue doesn't exist if I do a fresh `git clone` to another directory, so it begs the question of what fragility is present in worktrees that isn't in a fresh clone. In other words, I wouldn't feel safe doing weird Git operations in a worktree, so why use one in the first place? If I want a true throwaway repo, I'll just re-clone in another directory (and make sure to remove the remote, to be extra safe in case I accidentally push). Also, git worktree requires me to make a new directory anyway! So why would I not just put a fresh clone in there? To save a few megabytes of the .git index? [0] https://stackoverflow.com/a/39668520 https://stackoverflow.com/a/39668520
- frfl 3y ago
  You can make a temporary branch if you want an identical copy of a revision. For example, `git checkout feature-x` (on worktree 1), then `git checkout -b feature-x-temp feature-x` (on worktree 2). I've never had any issues with worktrees after heavy and extensive worktree usage since 2017. I use it regularly on big projects. The only time I had an issue with git was actually on a small non-worktree repo after 10 years of using git. The .git/ metadata got corrupted somehow, never understood why or how. When you have a worktree based workflow, you're getting the benefit of a single .git/ database managing them. Whereas if you have multiple standalone clones, you have to manually keep them up to date. With worktrees doing a `git fetch` will ensure all worktrees are able to do git operations on the most update to date git data. Whereas separate clones means you need to do N git fetches. Saving a few megabytes literally doesn't matter. Your project dependencies will likely use up tens if not hundreds of megabytes when you install them (pip packages, node modules, etc). Disk space is never really an issue anymore is it? Disks are hundreds of GBs now even on low end machines. I probably have multiple GBs of redundant disk usage because of my worktrees, but the convenience is well worth it IMO.
- jrockway 3y ago
  I find this very annoying. I don't know if this is the right thing or not, but my workflow for starting new work is "git checkout master; git pull; git checkout -b new_work". This is all fun and games until you have a worktree that's sitting at master. Now you have to figure out where that is, chdir there, and update that branch from the remote. It's actually extremely annoying. Maybe there is "git update master from remote and throw away my local changes because if i committed something there that was a mistake". But probably not, sadly, because technically the "git pull" operation to pull origin/master into the local tracking branch master updates the working copy where master is checked out, and that's what worktree is trying to avoid (changing a directory you're not in). I guess "git pull; git checkout -b new_branch remotes/origin/master" is what I should write, but that's more bytes to type.
  - wiredfool 3y ago
    git fetch origin git checkout -b new_work origin/master Git pull is essentially git fetch + merge. You don't have to update your local master branch to check out a new branch based on it.

azemetre 3y ago

I use to work at a company whose product had multiple versions of Java over its existence (literally think from Java 5 to Java 18), depending on the major product support versions (yes we had clients still on 1.0 system from the early 2000s, they were mostly regional banks). Worktrees made working on that monolith easier to do my types of tasks (updating tests that were specific to the UI team I was on, also the only person willing to touch java code). It sounds kinda backwards, but if you have to support multiple versions of a product that still brings in hundreds of millions in revenue it's nice to use git worktree to basically check out different versions of your product in time.