On 03/09/2012 09:48 AM, Thomas Rast wrote: > demerphq <demerphq@xxxxxxxxx> writes: > >> A possible solution might be to give config files a "format version" >> of their own. They already contain a repository format version number, >> so add a new variable "ConfigVersionLevel". Alongside that you might >> introduce a policy of having new git "fill in" the defaults missing >> from the config file whenever it operates, so that people can >> explicitly view then all at once. Then if the defaults change in the >> future an old repo will continue to work as it did before. This alone >> would allow you to change the defaults for existing configurable >> behavior, but you need the version number to handle new options. >> >> Once you have that you can change the default behavior based on the >> version level so that older users operating in older repositories get >> the old behavior, and new repositories get the new behavior. And you >> have more flexibility in how your approach these problems when they >> come up, and it seems to me that they are inevitable. > > This would be a brilliant way to confuse the hell out of existing users: > suddenly the apparent "defaults"[1] now change *between repositories* > depending on when they were created. > > In short, oh please god no. If config file version changes would occur rarely, then this idea dsoesn't sound that bad to me. git could even ask whether it should upgrade (explicitely insert the old default value if not existing and if different in the new release) the config file version whenver it encounters an old version. By this means old projects wouldn't be broken whenever a default value would be changed and all rconfig files would upgrade to the same version. Even older versions of git would still work with these upgraded config files -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html