Hello On Fri, Mar 15, 2024, at 08:23, Thomas Lowry wrote: > - throwaway/temp workspaces > One use case that I've seen alot is creating a workspace to handle > some hotfix and/or debugging and possibly commit the fix. Instead of > needing to actively manage this workspace (mostly the cleanup) I > imagine it would not be too dificult to these in the /tmp folder and > then cleanup/ignore their entries. Temp workspace file paths might > make this kind of tooling pointless unless you also automatically > change the working directory to the new workspace.. I've seen people > advocate for a git aliases that jump between workspaces but if your > adding the workspace and typing out the file path anyways then > `cd path` is shorter than an alias anyways. > - move hunks between workspaces > In my experience it's more common for a hotfix/debugging use case to > get the report and just use the current branch since it's not often > that your current branch is either completely broken or directly > conflicts with the reported bug. I usually don't stashing and changing > branches until I've got a fix and want to commit it. I recently tried > a workspace for this situation but I ended needing to retype the fix > in the new workspace, after reflecting a bit I should be able to do > `git stash -p` in the main workspace then `git stash pop` in the new > worktree but a dedicated way to move hunks would be quite useful. 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.[1] 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.) 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. † 1: My git-stash(1) bias: I don’t use it unless I am going to pop within the next half a minute. Mostly when I have an unintented dirty worktree in the middle of an interactive rebase. Kristoffer
