On Sun, Sep 23, 2018 at 10:25 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> > @@ -487,6 +487,28 @@ int submodule_uses_worktrees(const char *path)
> > +void strbuf_worktree_ref(const struct worktree *wt,
> > + struct strbuf *sb,
> > + const char *refname)
> > +{
> > + if (wt && !wt->is_current) {
> > + if (is_main_worktree(wt))
> > + strbuf_addstr(sb, "main/");
> > + else
> > + strbuf_addf(sb, "worktrees/%s/", wt->id);
> > + }
> > + strbuf_addstr(sb, refname);
> > +}
>
> Seeing this use worktree->id to construct "worktrees/<id>/<refname>"
> makes me wonder how the user is going to know the ID of a worktree in
> order to specify such refs in the first place. For example, how is the
> user going to know the <id> in "git rev-parse worktrees/<id>/HEAD"? I
> don't think we print the worktree ID anywhere, do we? Certainly, "git
> worktree list" doesn't show it, and "git worktree add" stopped showing
> it as of 2c27002a0a (worktree: improve message when creating a new
> worktree, 2018-04-24).
Oh yes I forgot to point this out. With this approach we have to have
an id, and the directory name inside $GIT_DIR/worktrees seems a
natural choice. I was hoping to go with extended ref syntax instead
[1] which gives us more flexibility in identifying a worktree. But I
don't think that's going to happen. "git worktree" would need some
improvements to show this id, specify it at "git worktree add" and
potentially rename it even.
[1] https://public-inbox.org/git/CACsJy8BOvU_z-uLrFmzFyryMXHNDfc_FUN_4i4NnVXWoShaBLQ@xxxxxxxxxxxxxx/
--
Duy
