On Tue, Sep 25, 2018 at 9:55 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > And with that said, I wonder if the "local" part should be feature agnostic, > > or if we want to be "local" for worktrees, "local" for remotes, "local" > > for submodules (i.e. our own refs vs submodule refs). > > You lost me here. Yeah, me too after rereading. :P I think the "local" part always implies that there is a part that is not local and depending on the feature you call it remote or other worktree. When writing this comment I briefly wondered if we want to combine the local aspects of the various features. However the "local" part really depends on the feature (e.g. a ref on a different worktree is still local from the here/remote perspective or from the superproject/submodule perspective), so I think I was misguided. > > > think as long as the word "worktree" is in there, people would notice > > > the difference. > > > > That makes sense. But is refs/worktree shared or local? It's not quite > > obvious to me, as I could have refs/worktree/<worktree-name>/master > > instead when it is shared, so I tend to favor refs/local-worktree/ a bit > > more, but that is more typing. :/ > > OK I think mixing the two patches will different purposes messes you > (or me) up ;-) possible. > > refs/worktrees/xxx (and refs/main/xxx) are about visibility from other > worktrees. Or like Eric put it, they are simply aliases. These refs > are not shared because if they are, you can already see them without > new "ref mount points" like this. > > refs/worktree (previously refs/local) is also per-worktree but it's > specifically because you can't have per-worktree inside "refs/" (the > only exception so far is refs/bisect which is hard coded). You can > have refs outside "refs/" (like HEAD or FETCH_HEAD) and they will not > be shared, but they cannot be iterated while those inside refs/ can > be. This is more about deciding what to share and I believe is really > worktree-specific and only matters to _current_ worktree. > > Since refs/worktree is per-worktree, you can also view them from a > different worktree via refs/worktrees/. E.g. if you have > refs/worktree/foo then another worktree can see it via > refs/worktrees/xxx/refs/worktree/foo (besides pseudo refs like > refs/worktrees/xxx/HEAD) Ah. now I seem to understand, thanks for explaining.
