Re: [PATCH v4] fetch: allow adding a filter after initial clone.

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

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Which is slightly different from what you did with the three-way
> split of verify_repository_format(), which made the "eligibility"
> thing not to care about unknown extensions in a repository v1 and
> higher.  I actually think we should refuse to update v1 or v2
> repository to v3 with a running Git that knows only about v1
> (i.e. the repository before upgrading may or may not be something we
> understand, and if we do not understand it, we shouldn't touch it).

It does not change the conclusion, but I think the above sample
situation would not make much sense---a caller that asks this
function to upgrade the repository to v3 when the version of Git it
is linked in does not understand v3 is simply buggy.

But we should still refuse to update v1 to v2 with a version of Git
that understands v2 if the repository has some extension that we do
not know about, so 

 (1) if upgrading from v0, there must be no "extensions.*"; and

 (2) if upgrading from other versions, there must be no
     "extensions.*" we do not recognise.

I suggested would still be the reasonably defensive rule.

Thanks.





[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