Re: [RFC - draft] List of proposed future changes that are backward incompatible

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

Hi,

On Sun, 15 Feb 2009, Jakub Narebski wrote:

quoted

david@lang.hm writes:

quoted

one thing that would help new users is if there was a way to create a
git config file that explicitly listed all the defaults. either as a
sample config, or to expand the existing config file with all the
defaults listed, but commented out.

I find that having such a config file helps me find config options I
never thought to look for.

That is a very good idea... if next to impossible now, I think, as
there is (I guess) no single place that stores default values.  But
perhaps I am mistaken.

if there isn't, wouldn't it be a good idea to make one?

Of course, you have to ignore the fact that it would no longer possible to
update defaults for existing repositories.

not if the defaults are put into the config file commented out.

this way you can see all the options (and default settings), but still 
tell which ones are system defaults and which ones the user has set. I 
have seen several projects that ship a config file that consists almost 
entirely of commented out items.

also, the first option I listed was to create a new file on-command that 
would contain the defaults

For example, setting something like receive.denyCurrentBranch to a saner
default would not reach existing repositories.

And you would also have to ignore the fact that sometimes, config
variables are deprecated, and this _also_ would not reach existing
repositories.  Of course, the same holds true if you set such a config
variable manually, but then you are _supposed_ to know the config
variable, and you are unlikely to learn the name of an obsolete variable.

Do keep in mind, too, that most of the variables are next to useless
without the proper documentation.

in most cases the variable names are fairly descriptive. even if you have 
to go to the documentation to figure out what to set it to, seeing the 
name can point you to the right thing to search for in the documentation.

And do you really want to replicate
Documentation/config.txt in the config file?  If not, how do you want to
make sure that the two different documentations do not go out of sync?

have one be auto-generated from the other and they won't be out of sync.

also note that I'm suggesting a git-config option that does this. not 
having it set at git-init time, so that users can run it long after the 
repository was created and see the defaults for the current version of 
git.

Further, it would be much, much harder to see what is _actually_ set.

again, not if the defaults are put in as commented out options

Summary: I do not like that idea.

I'm not sure the idea you dislike so much is exactly what I proposed.

David Lang