On Thu, 29 Sep 2016 at 04:44:00, SZEDER Gábor wrote: > I for one raise my hand in protest... > > "few extra bytes" is not the only downside, and it's not at all about > how many characters are copy-and-pasted. In my opinion it's much more > important that this change wastes 5 columns worth of valuable screen > real estate e.g. for 'git blame' or 'git log --oneline' in projects > that don't need it and certainly won't ever need it. > > 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. 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. Opinions? Regards, Lukas