On Wed, Jul 13, 2016 at 10:20 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Duy, > > On Tue, 12 Jul 2016, Duy Nguyen wrote: > >> On Tue, Jul 12, 2016 at 5:51 PM, Jeff King <peff@xxxxxxxx> wrote: >> > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote: >> > >> >> I'm not opposed to letting one worktree see everything, but this move >> >> makes it harder to write new scripts (or new builtin commands, even) >> >> that works with both single and multiple worktrees because you refer >> >> to one ref (in current worktree perspective) differently. If we kill >> >> of the main worktree (i.e. git init always creates a linked worktree) >> >> then it's less of a problem, but still a nuisance to write >> >> refs/worktree/$CURRENT/<something> everywhere. >> > >> > True. I gave a suggestion for the reading side, but the writing side >> > would still remain tedious. >> > >> > I wonder if, in a worktree, we could simply convert requests to read or >> > write names that do not begin with "refs/" as "refs/worktree/$CURRENT/"? >> > That makes it a read/write-time alias conversion, but the actual storage >> > is just vanilla (so the ref storage doesn't need to care, and >> > reachability just works). >> >> A conversion like that is already happening, but it works at >> git_path() level instead and maps anything outside refs/ to >> worktrees/$CURRENT. > > Wouldn't you agree that the entire discussion goes into a direction that > reveals that it might simply be a better idea to require commands that want > to have per-worktree refs to do that explicitly? No. To me that's equivalent to let people deal explicitly with file-based and lmdb refs backends everywhere. Unless the main worktree concept will die (I doubt it) it may remain the common use case that people care about and extra worktrees become second citizen that's rarely tested. I prefer we have a single interface for dealing with _any_ worktree. If there are fallouts, we deal with them. > The same holds true for the config, BTW. I really have no love for the > idea to make the config per-worktree. It just holds too many nasty > opportunities for violate the Law of Least Surprises. > > Just to name one: imagine you check out a different branch in worktree A, > then switch worktree B to the branch that A had, and all of a sudden you > may end up with a different upstream! Everything in moderation. You wouldn't want to enable sparse checkout on one worktree and it suddenly affects all worktrees because core.sparsecheckout is shared. And submodules are known not to work when core.worktree is still shared. I will not enforce any rule (unless it's very obvious that the other way is wrong, like core.worktree). I will give you a rifle and you can either hunt for food or shoot your foot. In other words, you should be able to share everything if you like it that way while someone else can share just some config vars, or even nothing in config file. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html