On Sun, Aug 13, 2017 at 9:36 PM, Richard Maw <richard.maw@xxxxxxxxx> wrote: > Forewarning: I don't consider this work complete > and am unlikely to find time to finish it any time soon. > I've mostly sent this because it may include valuable feedback > on how well the ref storage backends works > from trying to use it to change how git namespaces work. > > Introduction > ============ > > I work on a git server called Gitano, > and I'd like to add support for git namespaces to: [...] Thanks so much for your efforts and your description of the problems that you faced. That will be really valuable for whomever might follow up on your work (even if it is you :-) ). > Unfortunately namespace handling was never implemented for any other part of git > and at least gitolite makes use of namespaces, > and will have to work around it not being implemented fully, > but implementing it more fully will break work-arounds. I agree that the current namespace feature is not a great foundation for future work. > [...] > Fortunately the pluggable ref backends work provided an easier starting point. :-) I'm glad my years-long obsession is finally yielding fruit. First a general comment about the approach... I've always thought that a workable "Git with namespaces" would probably look more like git worktrees: * One main repository holding all of the objects and all of the non-pseudo references. * One lightweight directory per namespace-view, holding the "core.namespace" config and the pseudorefs. HEAD should probably be stored in the main repository (?). Both the main repository and the namespace-view directories would probably be bare, though perhaps somebody can think of an application for allowing non-bare repositories. Even though this scheme implies the need for extra directories, I think that it would make it easier to fix a lot of your problems: * Each namespace-view could define its own namespace, quasi-permanently. You wouldn't have to pass it via the environment. (You might even want to *forbid* changing the namespace via the environment or command line!) So fetches and pushes from one namespace to another would work correctly. * There would be one place for each namespace-view's pseudorefs. You wouldn't have to squeeze them into a single reference tree. * The main repository would know all of the references of all of the namespace views, so maintenance tools like `git gc` would work without changes. * The namespace-view directories wouldn't be mistakable for full repositories, so tools like `git gc` would refuse to run in them. I think this would also make it a little bit harder for reference values to "leak" from one namespace-view to another. * Remote access could use different paths for different namespace-views. The externally-visible path need not, of course, be the same as the path of the namespace-view's directory. By the way, there are certainly still places in the code that don't go through the refs API (e.g., the one that Junio found). That's because the refs API has still not been used for anything very interesting, so the bugs haven't been flushed out. I see you've found some more. That's because you're doing something interesting :-) > [...] > Bugs > ---- > > Most boil down to how special refs like HEAD are handled. > > 1. Logged messages display the namespaced path, > which a human may deal with but confuses the test suite. I think it's clear that the logged messages should reflect the shorter reference names, and it is the test suite that needs to be fixed. > 2. Reflogs for namespaced HEAD are not updated. > > This is because resolving HEAD to split the transaction's updates > to add a log only update to HEAD works by transaction_prepare resolving HEAD > using its own ref store rather than the main one, > so the namespace translation isn't performed. > See split_head_update. > > The fix for this may be to move the transaction mangling out of the backend, > unless it should be implied that every backend implementation > must be responsible for symbolic ref reflog updates implicitly. It probably makes sense for the namespace layer to do this step. I think there is a similar problem with `split_symref_update()`. Here the problem is trickier, because you don't know how to split the update until you have locked the symref, but the locking necessarily has to happen in the main-repo backend. So I think there will be places where the main-repo backend needs to call back to the namespace layer for some things, like deciding what reference names to use in error messages and things. You'd also want to prevent actions in a namespace-view from affecting references outside of that namespace. For example, you shouldn't be able to follow a symref from a namespace-view ref to another reference in a different namespace. This also implies some cooperation between the file-level backend and the namespace layer. I guess it is also clear that symrefs on disk have to contain the full reference names of their targets, but when they are read via a namespace-view, the caller should see the short name as the target. [...] Michael
