Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> No, the point is, refs subsystem needs to know which refs is per-repo, >> which is per-worktree. So far the rules are "everything under refs, >> except a few known exceptions, is per-repo" and "everything directly >> under $GIT_DIR is per-worktree", which work fine. But if you allow to >> move per-worktree to "refs" freely, then the "known exceptions" will >> have to be updated every time a new per-worktree ref appears. It'll be >> easier to modify the first rule as "everything under refs, except some >> legacy exceptions and refs/worktree, is per-repo". > > Given the substantial pain and suffering I have due to per-worktree > reflogs (and those are *just* HEAD's reflogs!), it appears to me that > per-worktree refs would be a particularly poor feature. > > I agree that HEAD needs to be per-worktree, but already the fact that the > HEADs of the worktrees, along with their reflogs, are *not* visible to > all other worktrees causes substantial trouble. Not so fast; it cuts both ways. People who want multiple worktrees with branches checked out to work in would want to do per-worktree things like bisection, which needs tons more state than we'd be comfortable having directly under $GIT_DIR (e.g. they may also want "git merge" or "git pull", which would use MERGE_HEAD and FETCH_HEAD that are per-worktree and not under refs/; "git bisect" would want to mark number of commits to denote the perimeter of the area of the history being bisected and they live refs/bisect/). And when you are bisecting in the worktree dedicated for a topic, it is a feature that your other worktrees do not need to see how much history you narrowed down in that topic. -- 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