Re: Possible to update-ref remote repository?

Jeff King <peff@peff.net> writes:

Yup.  It certainly is simpler if you can leverage existing helpers.

It will become even simpler in a reasonably modularlized world that hopefully may materialize before we all retire ;-). I am hoping that some of the folks who are interested in and talking about libification can be fooled into doing the necessary work to introduce proper abstraction, in addition to whatever they are doing.

Wouldn't it be great if you can have an in-core repository object, that knows what its object store is, has an index_state object that is tied to that object store, has a reference database whose values point into the object store, and if you can choose and mix these repository components' implementations? If done right, parts of the above set of components can be replaced with mock implementations that are in-core only.

To run "git push --repoint-only there 01beef23:master", you should be able to start your process totally outside an repository, yet create an in-core-only repository instance with an in-core-only object store instance, and because you took the object name to push on the command line, your in-core object store can "lie" to a call "create an in-core object for this SHA-1" by returning a fake in-core commit object, and your in-core-only ref database has that commit pointed at by some ref. Then because higher level "client" code to walk revisions, enumerate refs, etc., would all implement what they need to do by calling vtable of these in-core objects, you can do the "repoint-only" push without being in any repository, as such an implementation would not touch any filesystem (you can then plug in different implementation of object store etc., and even make them perform reasonably well if you manage to do the abstraction right).

But that would probably be at least 6 months away, even if we had a handful of competent developers totally dedicated to the effort without any distraction, which I do not know how likely it is to happen.