On Mon, 16 Feb 2009, Johannes Schindelin wrote:
Hi,
On Sun, 15 Feb 2009, Jakub Narebski wrote:
david@xxxxxxx writes:
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
--
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
