On Tue, Sep 25, 2018 at 4:35 AM Stefan Beller <sbeller@xxxxxxxxxx> wrote: > > On Sat, Sep 22, 2018 at 11:05 AM Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote: > > > > When multiple worktrees are used, we need rules to determine if > > something belongs to one worktree or all of them. Instead of keeping > > adding rules when new stuff comes, have a generic rule: > > > > - Inside $GIT_DIR, which is per-worktree by default, add > > $GIT_DIR/common which is always shared. New features that want to > > share stuff should put stuff under this directory. > > So that /common is a directory and you have to use it specifically > in new code? That would be easy to overlook when coming up > with $GIT_DIR/foo for implementing the git-foo. There's no easy way out. I have to do _something_ if you want to share $GIT_DIR/foo to all worktrees. Either we have to update path.c and add "foo" which is not even an option for external commands, or we put "foo" in a common place, e.g. $GIT_DIR/common/foo. > > - Inside refs/, which is shared by default except refs/bisect, add > > refs/local/ which is per-worktree. We may eventually move > > refs/bisect to this new location and remove the exception in refs > > code. > > That sounds dangerous to me. There is already a concept of > local and remote-tracking branches. So I would think that local > may soon become an overused word, (just like "index" today or > "recursive" to a lesser extend). > > Could this special area be more explicit? > (refs/worktree-local/ ? or after peeking at the docs below > refs/un-common/ ?) refs/un-common sounds really "uncommon" :D. If refs/local is bad, I guess we could go with either refs/worktree-local, refs/worktree, refs/private, refs/per-worktree... My vote is on refs/worktree. I think as long as the word "worktree" is in there, people would notice the difference. -- Duy
