Sorry for the slow reply but thank you for your thoughts, I'd love to hear others thoughts but it doesn't seem like this has caught very many people's attention. > For these two I use branches and commits. Like a WIP commit similar to > stashing if I want to get the changes out of the way quickly. I don’t > use worktrees for this. I'm pretty sure no one uses worktrees for these scenarios, the main question is more "IF improved tooling existed what kind of workflows could be streamlined?" ie things that you can already do another way. Thinking of brand new things you could do with a tool is a bit too open-ended, plus if someone is claiming that git would be so much better with feature X then they may just be happier using something else anyways. > I really like worktrees. I might use them for two very different > versions of the app. so that Intellij and other tools won’t get all > confused about their build state and indexing. Or a dedicated “deploy” > worktree for deploying the app with Docker (so that I can do whatever > else in the main worktree while it builds). There are a lot of > use-cases. And for the hotfix scenario: I might use a worktree when I > have to both commit some hotfixes and deploy them so that I can have a > dedicated scratchpad for that while I work on other things. (But also > not too much: too much multitasking is bad for me.) I haven't played much with these kind of long running worktrees, mostly because my projects don't currently have months old active feature/refactor branches that I'm slowly working through, also my CI/CD processes are fairly short so I don't know if I would be saving much time yet. Maybe in the future. > But I don’t see how worktrees enter into the picture in these specific > outlined scenarios for me. In particular I don’t understand moving hunks > between worktrees. Moving uncommitted hunks like that seems like a > version control layer on top of the Git database, like an extra step. Well in practical terms moving hunks is just a stash followed by a pop, so its not an exra layer on top of git just a recontextualization of a toolset git already gives you. Maybe another way to describe the use case is that someone is creating a worktree in order to commit a fix they already have instead of debug the problem since they were able to debug and test the fix on top of whatever else they happened to be doing at the time (yes sometimes work in progress will conflict with debugging but everyone has they're own strategy for dealing with that) A fundamental question is whether expanded worktree tooling is even needed, I'd say that there is existing evidence that it could be useful, for example https://gitbutler.com/ is arguably taking the core idea/problem of worktree's and turning it into a dedicated solution on top of Git. I'd also just like to note that whether intended or not Git is a toolbox, not every tool has to be useful to everyone. For example it can be argued that the primary use case of git (linux kernel development) is actually a minority use case because of how many people just use git with github and so tools like git-am have valid reasons for existing but is useful to almost none of the total population of developers. Regards, Thomas
