Re: Expanded worktree tooling?

["Kristoffer Haugsbakk" <code@khaugsbakk.name>]

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