Nickolai Belakovski <nbelakov...@gmail.com> writes: > Not trying to paint anything one way or another. I found that these > features got in the way of my workflows and didn't see any immediate > reason why they had to exist. Thinking about it a bit more, is it > unreasonable to delete a branch even if it's checked out in a worktree > as long as the user uses git branch --delete --force or -D?
[For ease of discussion, let's assume that our worktree has a checkout of branch B, and you are mucking with that branch in another worktree connected to the same repository] It is probably a sane enhancement to allow but require --force to delete branch B in the other worktree. It is a different matter to allow "git branch -m AnotherBranch B" run in the other worktree to overwrite branch B--it will be a disaster if we allowed it and then committed what we have in our worktree. > This would > leave the worktree in a detached head state, It does not. It will leave us on branch B that is unborn, and the next commit will start that branch with a root commit. > but all the data would be > untouched. As far as the person, who is working in our worktree, is concerned, she wanted to extend the history of branch B before you deleted it in another worktree. But because you deleted B while she was looking the other way, she ended up creating a root commit, losing all the history behind that branch. I'd grant you that "--force" will give us an excuse when she complains, though. Most likely, you and she are the same person, but one big point in the ability to work in multiple worktrees is to allow the user to switch context and multi-task. When she gives branch B its own worktree, she does so because she wants to have a stable place to work on it, without getting affected by other things she does to the repository in other worktrees.
