Re: [PATCH 3/8] refs: new ref types to make per-worktree refs visible to all worktrees
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Sep 29, 2018, 18:26 UTC
- Message-ID
- <CACsJy8AiVdXHNz362rixeUWj0Y4HknU93qqcT2EFMWVbsjwpJg@mail.gmail.com>
- In-Reply-To
- <xmqqy3bpnupm.fsf@gitster-ct.c.googlers.com>
On Tue, Sep 25, 2018 at 11:16 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> > Nguyễn Thái Ngọc Duy <pclouds@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.
Show 10 quoted lines
> 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