All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Jonathan Tan <jonathantanmy@google.com>,
	Derrick Stolee <stolee@gmail.com>, git <git@vger.kernel.org>,
	Taylor Blau <me@ttaylorr.com>
Subject: Re: [Question] Is extensions.partialClone defunct?
Date: Sat, 14 Mar 2020 07:43:55 +0100	[thread overview]
Message-ID: <CAP8UFD1ouu1EkJjGYuzJahZNX+QW-XyEPD-2Vfp8jMYNuVYkAA@mail.gmail.com> (raw)
In-Reply-To: <20200312230931.GF120942@google.com>

Hi,

On Fri, Mar 13, 2020 at 12:09 AM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Christian Couder wrote:
> >> Jonathan Tan wrote:
>
> >>> Hmm...besides giving the name of the promisor remote, the
> >>> extensions.partialClone setting is there to prevent old versions of Git
> >>> (that do not know this extension) from manipulating the repo.
> >
> > That could be true of "remote.<name>.promisor = true".
>
> To be clear, Jonathan is referring to a specific feature of the
> extensions.* settings.  See
> Documentation/technical/repository-version.txt for details:
>
>   2. If a version-1 repository specifies any `extensions.*` keys that
>      the running git has not implemented, the operation MUST NOT
>      proceed. Similarly, if the value of any known key is not understood
>      by the implementation, the operation MUST NOT proceed.
>
> No other config key has that property.

Yeah, right. I was very tired and it was late when I replied, so I was confused.

> > On Thu, Mar 12, 2020 at 6:51 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> >> Christian, what would your prefered way be to fix this?  Should
> >> extensions.partialclone specify a particular "default" promisor
> >> remote, or should we use a new repository extension for multiple
> >> promisors?
> [...]
> > So I'd rather obsolete "extensions.partialClone = <remote>" and to
> > find other ways.
>
> I *think* that means "new repository extension".

Yeah.

> That suggests something like
>
>         [extensions]
>                 multiplePromisors = true

Yeah, I think I suggested "[extensions]\npromisorremotes=<bool>" but
"multiplePromisors" is probably better.

> >                                                              or maybe
> > we could have another extension alltogether like
> > "[extensions]\npromisorremotes=<bool>" and over time obsolete
> > "extensions.partialClone" altogether. I prefer the later.
>
> I think we're going to have to continue to support
> extensions.partialClone=<remote> for a long time anyway (breaking the
> ability to work with existing repositories is expensive), so I'm
> reasonably comfortable with multiplePromisors being a separate
> extension.  Some faraway day, we can introduce
> "repositoryFormatVersion = 2" that mandates support for these
> extensions by default, allowing us to clean up and simplify.

Yeah, I agree.

> I can start writing a proposed patch to send this evening or tomorrow.

That would be very much appreciated! Thanks!

> This behavior has been around for a few releases so it would want to
> cook until the 2.27 cycle.

Yeah, and partial clone is experimental, so I think it's ok.

  reply	other threads:[~2020-03-15  4:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12 12:23 [Question] Is extensions.partialClone defunct? Derrick Stolee
2020-03-12 17:07 ` Jonathan Tan
2020-03-12 17:51   ` Jonathan Nieder
2020-03-12 18:10     ` Junio C Hamano
2020-03-12 21:09     ` Taylor Blau
2020-03-12 21:17       ` Junio C Hamano
2020-03-12 21:30         ` Jeff King
2020-03-12 21:54     ` Christian Couder
2020-03-12 21:59       ` Christian Couder
2020-03-12 23:09       ` Jonathan Nieder
2020-03-14  6:43         ` Christian Couder [this message]
2021-06-05 13:01           ` Tao Klerks
2020-03-13  0:10       ` 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=CAP8UFD1ouu1EkJjGYuzJahZNX+QW-XyEPD-2Vfp8jMYNuVYkAA@mail.gmail.com \
    --to=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=jrnieder@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=stolee@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 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.