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.
[1] using the word loosely here, for anything that the user has not
configured manually with git-config, git-remote, git branch
--set-upstream etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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