Re: [PATCH v2/GSoC/RFC] fetch: git fetch --deepen

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 22, 2015, 23:23 UTC
Message-ID: <CACsJy8A6ffMvySRUhfx8VCvTe2z+s7R-F6z+S+dex_xQ4kORKg@mail.gmail.com>
In-Reply-To: <39ef84113d77ee6fa371ac2f23bbb0ef321323ba.1427031746.git.dongcan.jiang@gmail.com>

On Sun, Mar 22, 2015 at 10:24 PM, Dongcan Jiang <dongcan.jiang@gmail.com> wrote:

Show 33 quoted lines

> This patch is just for discusstion. An option --deepen is added to
> 'git fetch'. When it comes to '--deepen', git should fetch N more
> commits ahead the local shallow commit, where N is indicated by
> '--depth=N'. [1]
>
> e.g.
>
>>  (upstream)
>>   ---o---o---o---A---B
>>
>>  (you)
>>                  A---B
>
> After excuting "git fetch --depth=1 --deepen", (you) get one more
> tip and it becomes
>
>>  (you)
>>              o---A---B
>
> '--deepen' is designed to be a boolean option in this patch, which
> is a little different from [1]. It's designed in this way, because
> it can reuse '--depth' in the program, and just costs one more bit
> in some data structure, such as fetch_pack_args,
> git_transport_options.
>
> Of course, as a patch for discussion, it remains a long way to go
> before being complete.
>
>         1) Documents should be completed.
>         2) More test cases, expecially corner cases, should be added.
>         3) No need to get remote refs when it comes to '--deepen' option.
>         4) Validity on options combination should be checked.
>         5) smart-http protocol remains to be supported. [2]

Quick notes before $DAYJOB starts. Cool pictures, perhaps they could be part of the commit message too.

Personally i still don't think not moving the refs is worth the effort (and it's a waste if we have to send then drop objects for these updated refs, but I didn't check carefully). So if you we don't needs ref updates, we probably don't need to send "want" lines and sort of simplify processing at upload-pack side.

And it makes me realise, we're loosing security a bit here. We normally don't send anything that's not reachable from the visible ref set. But we now would accept any shallow sha-1 and send some objects regardless if these sha-1 are connected to any refs. We may need some more checking in place to avoid this. See check_non_sha1_tip() for a way to do it. Pack bitmaps may help as well, but I think that's behind the scene (i.e. behind rev-list and we already can take advantage of it).

-- 
Duy