On Thu, Sep 29, 2016 at 07:27:01AM +0200, Lukas Fleischer wrote: > > Sure, users working on smaller repos are free to reset core.abbrev to > > its original value. I don't have any numbers, of course, but I > > suspect that there are many more smaller repos out there that this > > change will affect disadvantageously, than there are large repos for > > which it's beneficial. > > I know this suggestion comes a bit late but would it make sense to let > the repository owner overwrite the core.abbrev setting? > > One possible way to implement this would be adding .gitconfig support to > repositories with a very limited set of whitelisted variables allowed in > there (could be core.abbrev only to begin with). Or some entirely > separate mechanism like .gitignore. The suggestion for versioned repository-level config comes up from time to time; you can find other instances in the list archive. Usually the biggest issue is that usually nobody comes up with a good example of something that the project would actually want to set. Setting "core.abbrev" at least seems plausible. Though... > With such a mechanism, we could keep the default of 7 which works fine > for most projects. Linus could bump the default to 12 for linux.git. If > some users are not happy with that, they can still overwrite it in their > local Git config. Anybody starting a project could change the initial > value to a suitable value in one of the first commits -- provided they > already have an idea how much the project will grow. That way, hashes > will be "long enough" even for early commits, before any heuristics > could guess that the project would become large. I wonder if in practice we would do just as well to size default_abbrev dynamically based on the number of objects. That doesn't help projects which are just starting, but will eventually grow gigantic. But I doubt that most projects would have the foresight to preemptively set core.abbrev. And that would at least reduce the impact as the project _does_ get big. -Peff