Hacker News Reader

Comment by jomar | Hacker News Reader

If you had two worktrees set to the same branch and made a new commit in one of them (thus changing the commit the branch ref points to), what would happen in the other worktree?

Either it wouldn't have the right commit checked out anymore, or git would have to miraculously change what files are checked out in it -- which would likely come as a big surprise to whatever you were doing in that working tree.

Ergo, it is forbidden.

I periodically find myself creating a new (temporary) branch referring to the same commit when I want a new worktree looking at the same place, or just create a new worktree with a detached HEAD looking at the same commit.

View on HN

Git could hide this for you and just make it look like you cloned the repo twice.

What happens if you make a commit in dir1 and dir2 is on the same branch. Absolutely nothing, until you fetch, and worktrees could work the same way. If there is any ambiguity left you could prefix the branch names similar to the remotes origin/master, worktree2/master.

The only sane way to use worktrees today is, like you say, with detached heads. Which well…isn’t that sane for many other reasons.

If you want a separate clone you know where to find it, but then you will be plagued by the uncertainty I mentioned in my other comment (https://news.ycombinator.com/item?id=30400869).

I did not say that was the only sane way to use worktrees. I frequently use them for separate strands of ongoing work (on separate branches per work strand, named appropriately). Less common (for me) is the use case of easy reference to older versions, with more ephemeral worktrees checking out a tag, a new branch (created for the purpose, and short-lived), or a particular commit (viewed as a detached HEAD).

git could simply prevent you from committing to that branch in that case, and perhaps print a warning when adding a worktree. The current behavior is weird. Another alternative is to allow the commit, but leave it in a detached-head state, and let the user choose how to fix that retrospectively.

The way I use worktrees I'd say the majority are read-only anyhow, so abiding by restrictions because it might get confusing if a commit were made is pretty annoying.

Reply on news.ycombinator.com