Duy Nguyen <pclouds@xxxxxxxxx> writes: > The whole prune strategy is a bit messy trying to cover all cases > while still keeping out of the user's way. Perhaps if we implement > "git worktree mv", or even "worktree fixup" so the user can do it > manually (back when the prune strategy commit was implemented, there > was no git-worktree), then we don't need this magic any more. > > So, which way to go? I'd prefer to see "conservative and minimal first and carefully build up" instead of "snapping something together quickly and having to patch it up in rapid succession before people get hurt." and that is not limited to the "worktree" topic. I think "if you move, you are on your own, do not do it." would be a good starting point. The user education material would say: if you create worktree B out of the primary A, and if you do not like the location B, you "rm -fr B" and then create a new C out of the primary A at a desired place, and do not reuse location B for any other purpose. The list of worktrees kept somewhere in A would then name the old location B, and it is OK to notice the staleness and remove it, but we do not have to. At that point, the magic can and should go. After setting the user expectation that way, it is fine to design how we would give "worktree rm" and "worktree mv". As long as users' initial expectation is set to "you do not mv, ever", these can be introduced without hurting their established use pattern that would involve no 'mv'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html