On Fri, May 11, 2007 at 01:00:45AM +0200, Petr Baudis wrote: > However, in that case I think this is not the good point to show > ~/.gitconfig. Your goal at that point should be to get the user able > to commit as simply as possible, Sure. > and having to manually edit some config file is unnecessary hassle > when you can just use these two simple commands; I don't get it; why are the two commands "simple", and editing a file a "hassle"? In terms of, say, time required, or number of keystrokes, I suspect the two are about the same. And it seems to me that: - As users of a tool designed mainly to track changes to text files, git users are likely to be pretty proficient at editing text files. - People also need to be able to view the configuration and change it. If they make a typo on the first try, they may need to do this sooner rather than later. With a config file, this is trivial. With git-config, you have to learn at least one new thing (how to query values). - The config file is easier to read than the git-config output. - You're going to have to edit some text anyway to plug your name in, so we can't make this a pure cut-n-paste from the docs. > also, we use the same commands in tutorials, crash courses etc. So I > really think that consistency is better here. The more viable strategy > is to mention that git-config really just plays with simple text files > at some... later point. :-) So while I'm not convinced of the value of consistency here, if we have to have consistency, I'd rather standardize on config-file-editing. --b. - 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
