From: Stefan Beller <sbeller@google.com>
To: chenzero <chenzero@netease.com>, Jonathan Nieder <jrnieder@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: About connection resuming
Date: Tue, 20 Feb 2018 11:43:37 -0800 [thread overview]
Message-ID: <CAGZ79kYytJOFhzdpWnWNs574KeLQ2f1AtkdAQ1-o6P5=VO=r_Q@mail.gmail.com> (raw)
In-Reply-To: <b85f9654-3552-30c0-79bb-84fe10309d8b@netease.com>
On Tue, Feb 20, 2018 at 4:49 AM, chenzero <chenzero@netease.com> wrote:
> Hello,
> First, I am a user of git for about 2 years, I really appreciated you all to
> create this great useful software!
Hi, welcome to the mailing list!
> My encountered problem is:
> sometimes, the repo is big and because my networking is not stable(or my
> network proxy has
> some limitations), so, the clone will always fail.
> I tried following ways to solve this, however, not much success.
> 1. clone depth 1
> git clone --depth=1 https://..../repo.git
> however, some repo even depth=1 might fail.(It seemed that my network proxy
> limit tcp connection.
> if transfer over 50M, it will break)
> 2. download bundle file.
> but no all git repo provide bundle files to download.
>
> After some investment on the code, I think, perhaps,
> if enhance the git-http-backend to support http header: Range, or
> Content-Range,
> maybe it will enable connection resuming.
This thought has come up before, for example
https://public-inbox.org/git/1473984742-12516-1-git-send-email-kevin.m.wern@gmail.com/
(Or you can search for "resumable clone" in that mailing list archive,
there are more interesting discussions)
But the current problem is that the bytes of a clone are not stable,
as the packs are ordered racily IIUC: So if you clone the same repository
(with the same branch values), the observed communication over the wire
may differ in the part when the pack file is transferred as the packfile is
packed up in a multi threaded fashion, that has no clear order defined.
> the problem of this way is: it needs to upgrade the current deployed
> "git-http-backend",
> and maybe much code need to change including git-remote-http etc.
>
> This is the very basic thought, and whether I should try other way ?
> Thanks a lot!
I think a more promising approach is to have support for references
inside the packfile for transfer, this could become one of the features
of the new protocol that is being worked on
https://public-inbox.org/git/20180207011312.189834-1-bmwill@google.com/
I do not find a reference for the idea, but Jonathan (cc'd) laid it out
well once upon a time. Jonathan do you have a mailing list reference
for references in packfiles?
Thanks,
Stefan
prev parent reply other threads:[~2018-02-20 19:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-20 12:49 About connection resuming chenzero
2018-02-20 19:43 ` Stefan Beller [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='CAGZ79kYytJOFhzdpWnWNs574KeLQ2f1AtkdAQ1-o6P5=VO=r_Q@mail.gmail.com' \
--to=sbeller@google.com \
--cc=chenzero@netease.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/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).