On Tue, Sep 25, 2018 at 11:16 PM Junio C Hamano <gits...@pobox.com> wrote: > > Nguyễn Thái Ngọc Duy <pclo...@gmail.com> writes: > > > The main worktree has to be treated specially because well.. it's > > special from the beginning. So HEAD from the main worktree is > > acccessible via the name "main/HEAD" (we can't use > > "worktrees/main/HEAD" because "main" under "worktrees" is not > > reserved). > > I do not quite follow. So with this, both refs/heads/master and > main/refs/heads/master are good names for the master branch (even > though the local branch names are not per worktree), because > in the main worktree, refs/bisect/bad and main/refs/bisect/bad ought > to mean the same thing.
True. I think the ambiguation here is about the main worktree versus a secondary worktree that is accidentally named "main". Then suddenly we have to worktrees of the same name, and accessing them both via worktrees/<id>/HEAD will not work, and there is no other way to disambiguate them. > side note: Or is this only for pseudo-refs > (i.e. $GIT_DIR/$name where $name consists of all caps or > underscore and typically ends with HEAD)? Right now, due to implementation limitations, only pseudo refs (or loose refs in the case of refs/bisect) are accessible. But I don't see why main/refs/heads/master should not work. > The disambiguation rule has always been: if you have a confusingly > named ref, you can spell it out fully to avoid any ambiguity, e.g. > refs/heads/refs/heads/foo can be given to "git rev-parse" and will > mean the tip of the branch whose name is "refs/heads/foo", even when > another branch whose name is "foo" exists. > > Would we have a reasonable disambiguation rules that work well with > the main/ and worktrees/* prefixes? When somebody has main/HEAD branch > and writes "git rev-parse main/HEAD", does it find refs/heads/main/HEAD > or $GIT_DIR/HEAD, if the user is in the main worktree? The rules are not touched. But it looks like everything still works as expected (I'm adding tests to verify this) -- Duy
