From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Suvorov Ivan <sv_91@inbox.ru>, git <git@vger.kernel.org>
Subject: Re: Adding git hooks
Date: Sat, 26 Apr 2014 13:50:02 -0400 [thread overview]
Message-ID: <20140426175002.GC21493@sigill.intra.peff.net> (raw)
In-Reply-To: <7vy4yshul9.fsf@alter.siamese.dyndns.org>
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
> Suvorov Ivan <sv_91@inbox.ru> writes:
>
> > I want to extend the functionality of git due to the possibility of
> > separation of the user repository into 2 parts - one part will be
> > stored as usual, under version control git, and the second part will
> > be stored in another location such as an FTP-server.
>
> Sounds like you are looking for git-annex, perhaps?
I agree that is the right approach, but git-annex and git-media work
_above_ the object layer, and taint the history by storing symlinks in
git instead of the real sha1s. I'd love to see a solution that does the
same thing, but lives at the pack/loose object layer. Basically:
1. Teach sha1-file.c to look for missing objects by hitting an
external script, like:
git config odb.command "curl https://example.com/%s"
and place them in an alternates-like separate object database.
2. Teach the git protocol a new extension to say "don't bother sending
blobs over size X". You'd have to coordinate that X with the source
from your odb.command.
You'd probably want to wrap up the odb.command in a more fancy helper.
For example, for performance, we'd probably want to be able to query it
for "which objects do you have", as well as "fetch this object". And it
would be nice if it could auto-query the "X" for step 2, and manage
pruning local objects (e.g., when they become deep in history).
We'd probably also want to teach a few places in git to treat external
objects specially. For example, they should probably be auto-treated as
binary, so that a "log -p" does not try to fetch all of them. And
likewise, things like "log -S" should probably ignore them by default.
I have a messy sketch of step 1 that I did quite a while ago, but
haven't proceeded further on it.
-Peff
next prev parent reply other threads:[~2014-04-26 17:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-26 9:34 Adding git hooks Suvorov Ivan
2014-04-26 17:24 ` Junio C Hamano
2014-04-26 17:50 ` Jeff King [this message]
2014-04-28 16:43 ` Junio C Hamano
2014-04-28 19:11 ` Jeff King
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=20140426175002.GC21493@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sv_91@inbox.ru \
/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).