On Thu, Jan 25, 2018 at 2:08 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Wed, Jan 24, 2018 at 8:09 PM, Patryk Obara <patryk.obara@xxxxxxxxx> wrote: >> This extension selects which hashing algorithm from vtable should be >> used for reading and writing objects in the object store. At the moment >> supports only single value (sha-1). >> >> In case value of objectFormat is an unknown hashing algorithm, Git >> command will fail with following message: >> >> fatal: unknown repository extensions found: >> objectformat = <value> >> >> To indicate, that this specific objectFormat value is not recognised. >> >> The objectFormat extension is not allowed in repository marked as >> version 0 to prevent any possibility of accidentally writing a NewHash >> object in the sha-1 object store. This extension behaviour is different >> than preciousObjects extension (which is allowed in repo version 0). > > This config is so sensitive I wonder if we should forbid changing it > via git-config. You can't simply change this and expect anything to > work anyway. You may have a local tool to do so, "git convert-repo-to <newhash>", that would also adjust this setting. I'd second Johannes to not add special error handling and forbidding git-config to change this setting. > "git init" can have an option to specify object format. makes sense. > "git clone" > naturally inherits the format from the remote repository. not necessarily. As the hash transition plan suggests, you'd start with a local conversion, so it would make sense to have a "clone --convert-locally-to <newhash>" flag. > Maybe a > future command allows to convert hash algorithm on an existing repo > (*). But other than that nobody is allowed to change this. > > (*) it's probably git-clone that does this job, cloning and converting > at the same time. I think we also need on-the-fly conversion in fetch/push, so we can work converted locally, but pretend to the outside we speak sha1 just fine., Stefan
