Re: [PATCH] protocol: treat unrecognized protocol.version setting as 0

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

 



On 02/27, Jonathan Nieder wrote:
> If I share my .gitconfig or .git/config file between multiple machines
> (or between multiple Git versions on a single machine) and set
> 
> 	[protocol]
> 		version = 2
> 
> then running "git fetch" with a Git version that does not support
> protocol v2 errors out with
> 
> 	fatal: unknown value for config 'protocol.version': 2
> 
> In the spirit of v1.7.6-rc0~77^2~1 (Improve error handling when
> parsing dirstat parameters, 2011-04-29), it is better to (perhaps
> after warning the user) ignore the unrecognized protocol version.
> After all, future Git versions might add even more protocol versions,
> and using two different Git versions with the same Git repo, machine,
> or home directory should not cripple the older Git version just
> because of a parameter that is only understood by a more recent Git
> version.
> 
> So ignore the unrecognized value.  It may be useful for spell checking
> (for instance, if I put "version = v1" intending "version = 1") to
> warn about such settings, but this patch does not, since at least in
> these early days for protocol v2 it is expected for configurations
> that want to opportunistically use protocol v2 if available not to be
> unusual.
> 
> Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
> ---
> Google has been running with a patch like this internally for a while,
> since we have been changing the protocol.version number to a new value
> like 20180226 each time a minor tweak to the protocolv2 RFC occured.
> 
> The bit I have doubts about is whether to warn.  What do you think?

Patch looks good to me.  And I don't have a strong preference either way
for whether to warn or not.


-- 
Brandon Williams



[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