Expanded worktree tooling?

Expanded worktree tooling?

[Thomas Lowry]

Hello,

I recently learned about worktrees in git and I was wondering if some
extra tooling could benefit workflows that lean on it?

These are the use cases I have banging around in my head:
- 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.

I think there could be more opportunities for general use cases to
benefit from workspaces if there were extra workspace tooling but these
are the only ones I can think of, also to be clear I'm not really
considering any tooling that would allow workspaces to do something you
can't already do with git in some other way.

Thoughts?

Regards,
Thomas

Re: Expanded worktree tooling?

[Kristoffer Haugsbakk]

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

Re: Expanded worktree tooling?

[Thomas Lowry]

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