From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Jesse Hopkins <jesse.hops@gmail.com>, git@vger.kernel.org
Subject: Re: Possible to update-ref remote repository?
Date: Tue, 03 Oct 2023 18:13:36 -0700 [thread overview]
Message-ID: <xmqqil7ntcjj.fsf@gitster.g> (raw)
In-Reply-To: <20231003200018.GB1562@coredump.intra.peff.net> (Jeff King's message of "Tue, 3 Oct 2023 16:00:18 -0400")
Jeff King <peff@peff.net> writes:
> All that said, I do think it might be reasonable for git-push to support
> this directly.
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.
prev parent reply other threads:[~2023-10-04 1:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-30 16:34 Possible to update-ref remote repository? Jesse Hopkins
2023-09-30 17:17 ` Junio C Hamano
2023-10-01 22:03 ` Jesse Hopkins
2023-10-03 20:00 ` Jeff King
2023-10-04 1:13 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqil7ntcjj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jesse.hops@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).