On Wed, Jul 13, 2016 at 8:59 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: >> No. > > Oh? So you do not see that we are already heading into serious trouble > ourselves? I do see problems, that have solutions. But I have not yet seen that we are heading to a dead end. >> I prefer we have a single interface for dealing with _any_ worktree. > > I agree. So far, I did not see an interface, though, but the idea that we > should somehow fake things so that there does not *have* to be an > interface. Calling it "fake" is a bit too strong. I'd call it an abstraction. We have always had the one-repo/one-worktree relationship, now we're breaking that assumption. Some operations work at repo level and require a "repo view" while others work at worktree level. We do it in a way that a program designed with these separate views can still work correctly in the traditional one-worktree-one-repo configuration, where both views are the same. - For accessing data in $GIT_DIR, you do not peek directly into it any more. You use "git rev-parse --git-path" to retrieve a path in $GIT_DIR (instead of doing `git rev-parse --git-dir`/some/path), then you can do something about it. This is the equivalent of git_path() at C level. - We have a set of rules to define what part of $GIT_DIR is shared and what is not. When you add new stuff and follow this rule, it will work in single or multiple worktree config. So far pretty much every unknown thing is per-worktree. $GIT_DIR/common will be the shared place for external scripts, soon. - It's the same thing for refs: we may reserve a portion of it for per-worktree, and the rest is shared. - We provide means for one worktree to access data of any other worktree if needed (e.g. $GIT_COMMON_DIR, or the new ref storage API) - Because the majority of operations is per-worktree, that has been the default view so far when working in multiple worktrees. Repo-level operations such as git-gc, rev-list --all, fsck... need to "switch view". I missed this and this seemed to cause big problem for you. My only excuse is, this is an experimental feature. The idea of single config file with separate "worktree namespace" (eg. core.worktree vs worktree.<abc>.worktree) was shot down because it would result in a lot of changes. And it's the same thing why we start to split views this way (and make default view "per-worktree") instead of rewriting every piece of code to deal with multiple worktrees explicitly (by carrying the worktree id everywhere). There are two loose ends that are on my mind, but I have not clear ideas yet: the incorporation of ref namespace and odb alternates. Imagine when you you submodules, all submodule repos (refs and odb) can be stored in the top-level .git repo, separated by namespaces. After all a repo is just a container, of a bunch of refs. This make it much easier to peek into another submodule from a supermodule, and makes it safer to "rm -r a-submodule" when you get mad at something. I hope this shows that it is less of a fake thing. -- 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