Re: gc and repack ignore .git/*HEAD when checking reachability

On Wed, Jul 13, 2016 at 8:59 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I do see problems, that have solutions. But I have not yet seen that we are heading to a dead end.

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.