All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Xin Li <delphij@google.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrn@google.com>,
	Derrick Stolee <dstolee@microsoft.com>,
	Christian Couder <christian.couder@gmail.com>,
	Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH] fetch: allow adding a filter after initial clone.
Date: Wed, 13 May 2020 15:18:04 -0700	[thread overview]
Message-ID: <xmqqsgg3qy1v.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAOhzdui-4KeOit74fTy=3YxSncHGZzy+cE+6njyjHPyJ8xFpMA@mail.gmail.com> (Xin Li's message of "Wed, 13 May 2020 14:41:00 -0700")

Xin Li <delphij@google.com> writes:

> The proposed change would allow converting an existing git clone to
> use partial clones.  For example:
>
> $ git clone --depth=1 https://android.googlesource.com/platform/bionic .
> $ git fetch --unshallow --filter=blob:none origin
>
> Previously, to allow this one would have to do the following manually
> first; the existing code would handle the rest gracefully:
>
> $ git config core.repositoryFormatVersion 1
> $ git config extensions.partialClone origin
>
> And the proposed change would have git do it for the user
> automatically, the existing workflow remains otherwise unchanged.

Actually, do we even know, when we "upgrade" the repository with the
patch, that the 'origin' supports the required protocol extensions
like on-demand fetching of objects?

At "git clone" time, "git clone --filter=..."  against a server that
is not prepared to serve as a lazy clone's backup remote would fail,
so we will never write extensions.partialClone=origin when origin
cannot serve as such. 

But writing these config you suggest to "do manually" is already not
a safe thing to do, without making sure it is supported, no?  It
does not sound like a good idea to do an unsafe thing for the user
automatically.

Added a few folks on Cc: list, who know and care more about partial
clones than I do for input.

Thanks.

  parent reply	other threads:[~2020-05-13 22:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 20:00 [PATCH] fetch: allow adding a filter after initial clone Xin Li
2020-05-13 20:43 ` Junio C Hamano
2020-05-13 21:41   ` Xin Li
2020-05-13 22:07     ` Junio C Hamano
2020-05-13 22:18     ` Junio C Hamano [this message]
2020-05-13 23:44 ` brian m. carlson
2020-05-28  2:53   ` [PATCH v2 0/1] " Xin Li
2020-05-28  2:54   ` [PATCH v2 1/1] " Xin Li
2020-05-28  3:28     ` Jonathan Nieder
2020-05-28  4:08       ` [PATCH v3] " Xin Li
2020-05-28 15:04     ` [PATCH v2 1/1] " Junio C Hamano
2020-05-28 17:19       ` Jonathan Nieder
2020-05-28 19:12         ` Xin Li
2020-05-28 19:17           ` Jonathan Nieder
2020-05-29  0:04             ` [PATCH v4] " Xin Li
2020-05-29  0:41               ` Junio C Hamano
2020-05-29 18:00                 ` Junio C Hamano
2020-05-29  1:01               ` Jonathan Nieder
2020-05-29  6:44                 ` [PATCH v5] " Xin Li
2020-05-29  6:54                 ` [PATCH v4] " Xin Li
2020-05-29 18:06                 ` Junio C Hamano
2020-06-05  9:10                   ` [PATCH v6 0/4] " Xin Li
2020-06-05  9:10                     ` [PATCH v6 1/4] repository: add a helper function to perform repository format upgrade Xin Li
2020-06-05 19:12                       ` Junio C Hamano
2020-06-05  9:10                     ` [PATCH v6 2/4] fetch: allow adding a filter after initial clone Xin Li
2020-06-05 19:15                       ` Junio C Hamano
2020-06-05  9:10                     ` [PATCH v6 3/4] sparse-checkout: upgrade repository to version 1 when enabling extension Xin Li
2020-06-05 19:21                       ` Junio C Hamano
2020-06-05  9:10                     ` [PATCH v6 4/4] check_repository_format_gently(): refuse extensions for old repositories Xin Li
2020-06-08 16:59                       ` Junio C Hamano

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=xmqqsgg3qy1v.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=delphij@google.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=jrn@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.