It might make sense in JAVA world, where IDEs load the whole tree and still don't play nice with everything changing on them (Windows?); So you'd equate "branch" with "workdir" and "disk path", and don't bother the IDE about it.

It also sounds like an easier way to do "git clone --reference", which is actually kinda easy anyway, so IDK.

One use case is indeed in the Java world (we're a Java shop). But support for this would also be really useful in situations where you're working on a feature (or several different features) orthogonally in different branches, and sometimes have uncommitted files lying around you don't want to commit just yet, and have to perform reviews on other people's code to boot. So - a technical team lead would encounter this.

Without git worktree, you'd have to remember to pop the stash after you're done.

But anyway, I agree that it's a "nice to have" but not a high priority for now. I could always work on the main repo checkout when landing the feature in question.

So - a technical team lead would encounter this.

I'd describe myself as this, at least approximately, but never have files lying around that I don't want to commit. Why wouldn't you want to commit a file?

sometimes have uncommitted files lying around you don't want to commit just yet

I'm in a Java + Mercurial shop -- this situation sometimes comes up, but I've gotten in the habit of just committing the changes as-is (even if not compilable). Both mercurial and git support amending commits, so it's usually trivial to make a "transient" commit, come back to pick it up later. Alternative to an amend, I had considered making an hg alias which would essentially dump the last commit back into working dir state (I wouldn't be surprised if there's already a way to do this in hg):

1. export commit to patch
2. strip commit
3. apply patch with --no-commit

There might be some benefit I'm not aware of with git related to the index which I think is additional state a user might want to keep around?

In T9924#147596, @epriestley wrote:

So - a technical team lead would encounter this.

I'd describe myself as this, at least approximately, but never have files lying around that I don't want to commit. Why wouldn't you want to commit a file?

In my situation, this normally comes up when I'm still exploring the problem space for a particular feature. The alternative is, as @cspeckmim says, to just commit anyway and later amend them (or, in Git, squashing the changes etc.).

With worktree, if I'm finding myself suddenly having to abandon the exploration to work on something urgent, I can just start a new work tree off of master in a different directory, and it starts in a clean state - no need to stash.

Though we're a Java shop, funnily enough, this is happening during a major refactoring of our orchestration playbooks written in Ansible. While there is less of a need for it once things settle down, the "never having to deal with the stash stack" alone is probably worth using work trees -- we're using it now despite the slight annoyance with arc land!