Hi Junio, On Wed, 29 Mar 2017, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > The approach I chose instead was to make the switch global, per > > command. Obviously, the next step is to identify the Git commands > > which accept objects from external sources (`clone`, `fetch`, > > `fast-import` and all the remote helpers come to mind) and let them > > set a global flag before asking git_default_config() to parse the > > core.enableSHA1DC setting, so that the special value `external` could > > trigger the collision detecting code for those, and only those, > > commands. That would still err on the safe side if these commands are > > used to hash objects originating from the same machine, but that is a > > price I would be willing to pay for the simplicity of this approach. > > > > Does my explanation manage to illustrate in a plausible way why I > > chose the approach that I did? > > I agree that there may be rooms to tweak the degree of paranoia per > codepath (I said that already in the message you are responding to), > but as Linus and Peff already said in the old discussion thread > [*3*], I doubt that it needs to be runtime configurable. My real world scenario here was intended to cast a spell on your doubts: the very real slow down is very inacceptable. Given your reluctance to accept that the performance impact is large enough to be painful, and that there are situations where the trust in your infrastructure and your colleagues makes that pain unnecessary, you leave me no other option than to make this a Git for Windows-only feature. I really tried to reconcile your concerns with the needs of Git for Windows' users, to demonstrate that the compile-time switch is unacceptable, but it is time to accept defeat and the newly acquired maintenance burden. Moving on, Dscho