Re: [Question] Is extensions.partialClone defunct?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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.

[...]
> On Thu, Mar 12, 2020 at 6:51 PM Jonathan Nieder <jrnieder@xxxxxxxxx> 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".

That suggests something like

	[extensions]
		multiplePromisors = true

[...]
>                                                              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.

I can start writing a proposed patch to send this evening or tomorrow.
This behavior has been around for a few releases so it would want to
cook until the 2.27 cycle.

Thanks,
Jonathan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux