Re: Expanded worktree tooling?

["Thomas Lowry" <thomas@bit-artificer.com>]

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