From: Duy Nguyen <pclouds@gmail.com>
To: Dongcan Jiang <dongcan.jiang@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [GSoC/RFC] Ideas on git fetch --deepen
Date: Sun, 8 Mar 2015 16:34:41 +0700 [thread overview]
Message-ID: <CACsJy8B5HwwZei+ao6Z4dt1eG27Mj4z2_QDKzVPTLphm6JrVWA@mail.gmail.com> (raw)
In-Reply-To: <CABwkPcoWUcK2vzqUBcEcuNzizYMtP=qUiew2HmDgqtivfDXbDg@mail.gmail.com>
On Sun, Mar 8, 2015 at 3:57 PM, Dongcan Jiang <dongcan.jiang@gmail.com> wrote:
> Hi, all
>
> After digging into how "git fetch" works, I have found that my previous
> understanding was too rash. I'm sorry for that.
>
> I find that the current workflow of "git fetch --depth" is as follows:
>
> 1. 'fetch module' calls 'git-upload-pack service' via 'transport module'
> to fetch ref with `depth`.
> 2. Such call is finished by pipe I/O.
> 3. git-upload-pack receives arguments such as 'depth' to fetch commits,
> and send back to the caller.
>
> Therefore, if we want to implement "--deepen" for "git fetch", we have to
> modify the arguments protocol of git-upload-pack service by adding the
> 'shallow commit' hash.
> Then, we can fetch `depth` commits before the 'shallow commit' in
> git-upload-pack service.
> Apparently, we have to output error message when the 'shallow commit' hash
> is not in the repository.
Close. You can't figure this shallow commit hash from client side
(client repo is shortened). So you can't send it. What you send is
exactly what the user gives you (e.g. --deepen=5, then you send
"deepen 5" or similar). The server side (git-upload-pack) knows about
the shallow boundary of the client and can walk its (i.e. server-side)
commit graph to find out the new, deepened boundary. Then the server
sends necessary objects plus instructions to update shallow boundary
to the client.
Also, I think this work would include support for smart-http
protocol. It goes a slightly different route, "git fetch" ends up at
transport.c, but then transport-helper.c and calls git-remote-http(s)
which is implemented by remote-curl.c. This one handles http stuff
then passes control to git-fetch-pack.c. It's fetch-pack that talks to
upload-pack.c
Have a look at Documentation/technical/pack-protocol.txt and
protocol-capabilities.txt (and http-protocol.txt for smart-http). The
function that "draws" shallow boundary based on --depth is
get_shallow_commits() in shallow.c. I suspect you need to improve it a
bit to use with --deepen. I guess you can look at these [1]. Those
changes touch shallow repo in a bit different way, but the main code
path is more or less the same (smart-http not touched).
[1] https://github.com/pclouds/git/commits/7edde8b83a20abb3cd404e2c5f07e3c29a2891f7
--
Duy
next prev parent reply other threads:[~2015-03-08 9:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 6:32 [GSoC/RFC] Ideas on git fetch --deepen Dongcan Jiang
2015-03-08 8:57 ` Dongcan Jiang
2015-03-08 9:34 ` Duy Nguyen [this message]
2015-03-08 10:14 ` Dongcan Jiang
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=CACsJy8B5HwwZei+ao6Z4dt1eG27Mj4z2_QDKzVPTLphm6JrVWA@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=dongcan.jiang@gmail.com \
--cc=git@vger.kernel.org \
/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).