Hi Junio, On Mon, 11 Jul 2016, Junio C Hamano wrote: > 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/). Sure, `git bisect` would need to realize that it is running in a worktree separate from the original one and use a different ref. > 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. If you intentionally hide bisections from other worktrees, you will invariably end up with the same problems I faced with auto-gc: in a worktree, it is *much, much easier* to forget a bisect in progress. In other words, your comments make me even more certain that per-worktree refs are undesirable. Ciao, Dscho -- 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