On Tue, Dec 03, 2024 at 09:46:12AM +0900, Junio C Hamano wrote:
> shejialuo <shejialuo@xxxxxxxxx> writes:
>
> > But cross-ref operations between worktrees must explicitly specify the
> > worktree id, so I am wondering whether we should allow the user do
> > cross-ref operations in the first place:
> >
> > 1. main worktree symref points to linked worktree ref.
> > 2. A linked worktree ref points to another linked worktree ref.
>
> What is a cross-ref operation? A worktree is either the primary
> working tree for a (non-bare) repository, or something added with
> "git add worktree" (i.e. whose .git is not the repository but a
> link file into the real repository). Are you adding another mode
> where a worktree points at another worktree and not the repository?
I am sorry that my words may confuse you here. And the Eric has already
explained what I mean here. At current, we have the ability to mention
a ref another worktree within the current worktree. You also have tole
me that in [1], there is a possibility that the user could create a
symbolic link to some worktree-specific ref in another worktree.
So, if our intention is to deliberately hide the worktree id. Why we
allow such ability? Let me give an example.
If we are in the main-worktree, and we want to access the worktree
specified refs, we must specify the worktree id like the following
(also if we are in the linked-worktree, we want to access another
linked-worktree refs):
worktrees/<worktree id>/refs/worktree/foo
We do not want to the user know the worktree id. However, we allow
above. This is something I feel really strange during the review
process. To the front-end user, the worktree path is the interface.
However, for above ability, we need the user to explicitly specify the
worktree id.
