{"thread":{"id":"61125","subject":"Expanded worktree tooling?","startedAt":"2024-03-15T07:30:37Z","lastAt":"2024-04-02T07:10:07Z","messageCount":3,"participants":["Thomas Lowry","Kristoffer Haugsbakk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"490677","messageId":"CZU56XWOUT4P.1WZ2BSE0VLN01@bit-artificer.com","threadId":"61125","inReplyTo":null,"subject":"Expanded worktree tooling?","fromName":"Thomas Lowry","fromEmail":"thomas@bit-artificer.com","sentAt":"2024-03-15T07:23:59Z","receivedAt":"2024-03-15T07:30:37Z","isPatch":false,"sender":{"key":"thomas@bit-artificer.com","avatar":null},"body":"Hello,\n\nI recently learned about worktrees in git and I was wondering if some\nextra tooling could benefit workflows that lean on it?\n\nThese are the use cases I have banging around in my head:\n- throwaway/temp workspaces\n  One use case that I've seen alot is creating a workspace to handle\n  some hotfix and/or debugging and possibly commit the fix. Instead of\n  needing to actively manage this workspace (mostly the cleanup) I\n  imagine it would not be too dificult to these in the /tmp folder and\n  then cleanup/ignore their entries. Temp workspace file paths might\n  make this kind of tooling pointless unless you also automatically\n  change the working directory to the new workspace.. I've seen people\n  advocate for a git aliases that jump between workspaces but if your\n  adding the workspace and typing out the file path anyways then\n  `cd path` is shorter than an alias anyways.\n- move hunks between workspaces\n  In my experience it's more common for a hotfix/debugging use case to\n  get the report and just use the current branch since it's not often\n  that your current branch is either completely broken or directly\n  conflicts with the reported bug. I usually don't stashing and changing\n  branches until I've got a fix and want to commit it. I recently tried\n  a workspace for this situation but I ended needing to retype the fix\n  in the new workspace, after reflecting a bit I should be able to do \n  `git stash -p` in the main workspace then `git stash pop` in the new\n  worktree but a dedicated way to move hunks would be quite useful.\n\nI think there could be more opportunities for general use cases to\nbenefit from workspaces if there were extra workspace tooling but these\nare the only ones I can think of, also to be clear I'm not really\nconsidering any tooling that would allow workspaces to do something you\ncan't already do with git in some other way.\n\nThoughts?\n\nRegards,\nThomas\n"},{"id":"490707","messageId":"028f7834-7695-4702-ada3-7fe74e8cbea7@app.fastmail.com","threadId":"61125","inReplyTo":"CZU56XWOUT4P.1WZ2BSE0VLN01@bit-artificer.com","subject":"Re: Expanded worktree tooling?","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2024-03-15T19:12:54Z","receivedAt":"2024-03-15T19:13:16Z","isPatch":false,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"Hello\n\nOn Fri, Mar 15, 2024, at 08:23, Thomas Lowry wrote:\n> - throwaway/temp workspaces\n>   One use case that I've seen alot is creating a workspace to handle\n>   some hotfix and/or debugging and possibly commit the fix. Instead of\n>   needing to actively manage this workspace (mostly the cleanup) I\n>   imagine it would not be too dificult to these in the /tmp folder and\n>   then cleanup/ignore their entries. Temp workspace file paths might\n>   make this kind of tooling pointless unless you also automatically\n>   change the working directory to the new workspace.. I've seen people\n>   advocate for a git aliases that jump between workspaces but if your\n>   adding the workspace and typing out the file path anyways then\n>   `cd path` is shorter than an alias anyways.\n> - move hunks between workspaces\n>   In my experience it's more common for a hotfix/debugging use case to\n>   get the report and just use the current branch since it's not often\n>   that your current branch is either completely broken or directly\n>   conflicts with the reported bug. I usually don't stashing and changing\n>   branches until I've got a fix and want to commit it. I recently tried\n>   a workspace for this situation but I ended needing to retype the fix\n>   in the new workspace, after reflecting a bit I should be able to do\n>   `git stash -p` in the main workspace then `git stash pop` in the new\n>   worktree but a dedicated way to move hunks would be quite useful.\n\nFor these two I use branches and commits. Like a WIP commit similar to\nstashing if I want to get the changes out of the way quickly. I don’t\nuse worktrees for this.[1]\n\nI really like worktrees. I might use them for two very different\nversions of the app. so that Intellij and other tools won’t get all\nconfused about their build state and indexing. Or a dedicated “deploy”\nworktree for deploying the app with Docker (so that I can do whatever\nelse in the main worktree while it builds). There are a lot of\nuse-cases. And for the hotfix scenario: I might use a worktree when I\nhave to both commit some hotfixes and deploy them so that I can have a\ndedicated scratchpad for that while I work on other things. (But also\nnot too much: too much multitasking is bad for me.)\n\nBut I don’t see how worktrees enter into the picture in these specific\noutlined scenarios for me. In particular I don’t understand moving hunks\nbetween worktrees. Moving uncommitted hunks like that seems like a\nversion control layer on top of the Git database, like an extra step.\n\n† 1: My git-stash(1) bias: I don’t use it unless I am going to pop\n   within the next half a minute. Mostly when I have an unintented dirty\n   worktree in the middle of an interactive rebase.\n\nKristoffer\n"},{"id":"492027","messageId":"D09G10B0SW3P.3ORJXEY5FUUU0@bit-artificer.com","threadId":"61125","inReplyTo":"CZU56XWOUT4P.1WZ2BSE0VLN01@bit-artificer.com","subject":"Re: Expanded worktree tooling?","fromName":"Thomas Lowry","fromEmail":"thomas@bit-artificer.com","sentAt":"2024-04-02T07:03:26Z","receivedAt":"2024-04-02T07:10:07Z","isPatch":false,"sender":{"key":"thomas@bit-artificer.com","avatar":null},"body":"Sorry for the slow reply but thank you for your thoughts, I'd love to\nhear others thoughts but it doesn't seem like this has caught very many\npeople's attention.\n\n> For these two I use branches and commits. Like a WIP commit similar to\n> stashing if I want to get the changes out of the way quickly. I don’t\n> use worktrees for this.\n\nI'm pretty sure no one uses worktrees for these scenarios, the main\nquestion is more \"IF improved tooling existed what kind of workflows\ncould be streamlined?\" ie things that you can already do another way.\nThinking of brand new things you could do with a tool is a bit too\nopen-ended, plus if someone is claiming that git would be so much better\nwith feature X then they may just be happier using something else\nanyways.\n\n> I really like worktrees. I might use them for two very different\n> versions of the app. so that Intellij and other tools won’t get all\n> confused about their build state and indexing. Or a dedicated “deploy”\n> worktree for deploying the app with Docker (so that I can do whatever\n> else in the main worktree while it builds). There are a lot of\n> use-cases. And for the hotfix scenario: I might use a worktree when I\n> have to both commit some hotfixes and deploy them so that I can have a\n> dedicated scratchpad for that while I work on other things. (But also\n> not too much: too much multitasking is bad for me.)\n\nI haven't played much with these kind of long running worktrees, mostly\nbecause my projects don't currently have months old active\nfeature/refactor branches that I'm slowly working through, also my CI/CD\nprocesses are fairly short so I don't know if I would be saving much\ntime yet. Maybe in the future.\n\n> But I don’t see how worktrees enter into the picture in these specific\n> outlined scenarios for me. In particular I don’t understand moving hunks\n> between worktrees. Moving uncommitted hunks like that seems like a\n> version control layer on top of the Git database, like an extra step.\n\nWell in practical terms moving hunks is just a stash followed by a pop,\nso its not an exra layer on top of git just a recontextualization of a\ntoolset git already gives you.\n\nMaybe another way to describe the use case is that someone is creating a\nworktree in order to commit a fix they already have instead of debug the\nproblem since they were able to debug and test the fix on top of\nwhatever else they happened to be doing at the time (yes sometimes work\nin progress will conflict with debugging but everyone has they're own\nstrategy for dealing with that)\n\nA fundamental question is whether expanded worktree tooling is even\nneeded, I'd say that there is existing evidence that it could be useful,\nfor example https://gitbutler.com/ is arguably taking the core\nidea/problem of worktree's and turning it into a dedicated solution on\ntop of Git.\n\nI'd also just like to note that whether intended or not Git is a\ntoolbox, not every tool has to be useful to everyone. For example it can\nbe argued that the primary use case of git (linux kernel development) is\nactually a minority use case because of how many people just use git\nwith github and so tools like git-am have valid reasons for existing but\nis useful to almost none of the total population of developers.\n\nRegards,\nThomas\n"}]}