Because it will completely screw with anyone who actually wants it in the per-repo config file. If I'm new to git, and my first usage is on a sample project, and git prompts me then I'll put in my personal contact information. But then if I go and start working on my company's git project, it will never prompt me again and I'll accidentally be committing company code under my personal email address. And I would be perfectly justified in blaming git's faulty user interface for letting that happen. At least if I set the config myself I _know_ I'm placing it in the global config file.

Your use case makes sense, but

1) Git's current initial setup UI would not prevent the user from making that mistake. It might make them feel stupid when they remember, but that's not the same thing as usability. The commit interface displays your identity and might throw up a red light.

2) Having made this mistake, a new user isn't going to remember the "git config" or "git commit --amend" commands they copied when prompted (if they remember entering them at all; I didn't remember exactly how initial setup worked). They're going to have to go look them up anyway.

3) Every user of Git will have a global username/email. Not every user will set them on a per-repo basis.

I guess I'm wondering why Git inconveniences everyone in deference to the less common use case.

In the common case, a lack of username/email actually indicates a configuration error. Blindly offering to set username/email may cause people to "fix" their config by re-setting username/email when in fact the lack of this is indicative of some other issue. Sure, _everybody_ sets up git once, but on the other hand, everybody sets up git _once_. The common use case is, by far, running with git already configured.

I dispute this claim. There are only very few ways your ~/.gitconfig can be corrupted:

1. You edited it by hand and fucked up the syntax. In this case git could print an error instead if offering to add the username/email.

2. You deleted itself. When git asks you for the username/email again it'll actually tell you that that file was for storing the username/email.

3. Filesystem error. A faulty gitconfig with be the last thing the user is worrying about.

All in all I don't see how all of this would imply that prompting a username/email isn't a good idea.

In the absence of a ~/.gitconf file, how is offering to set username/email more damaging than instructing the user to set them manually?

If the user doesn't think something is odd when the program wants initial setup info again, there's no helping them either way.

This sounds horribly elitist. You absolutely must use the command line and an editor in order to use git? Sure, I guess. If you get to spend all day working with neckbeards.

For the rest of us, having a pretty UI helps. And I don't see how is being user friendly and offering to just do it can ever be a bad thing. Especially when the alternative is forcing people to figure out how a config file works. Should it be in ~/.gitconfiguration? ~/.gitconfig? Whats that . mean? That ~? A typo'd and it gets made it in ~/.gticonfig..

I have some stuff in my gitconfig that I like having, but, would never be able to figure it out if someone didn't A. tell me what to do or B. make a script that did it for me. And no, I didn't enjoy reading dozens of git manpages to try and find what I wanted. It really sucked.

Where's this rule that just because it is text based means that it has to be ugly? I seem to have missed the memo on it.

You're arguing in favor of having a "pretty UI" _at the expense_ of functionality. That's absolutely inappropriate for a command-line tool, especially one that was originally designed for use by hard-core computer programmers. If you want a pretty UI, go use a tool that wraps Git and provides one, like I just suggested. Sure, if you want to suggest that Git's error upon not having a username/email is made a bit friendlier, that's a reasonable suggestion. But you're suggesting something which would actually be a negative change for a lot of people (i.e. changing a hard error into a potential data loss situation).

Here is how I read this thread - someone links to a tool that wraps git with a prettier command line UI, you say that you don't need that, here's some magical aliases, others say but those aren't pretty like the tool we were originally discussing, you say "if you want a pretty UI, go use a tool that wraps Git and provides one" ...like the one from the original link? I don't get your argument, is there a reasonable place for prettier UIs wrapping common Git commands, or do we all just need to be more hardcore and learn to write good aliases?

Did you even read the OP? There is no tool. It's a blog post with a wish list for a magical tool that the author wants someone to create. Try reading the article next time before you go argue in the comments.

Can you folks who are downvoting me please tell me _why_ you are doing this? We're not on reddit. What I posted is absolutely not deserving of downvotes. If you disagree with me, post a reply.

I'm not the guy who voted you down, but I'm guessing other people did it because your posts' attitude imply that new users are absolutely not worth accommodating for and that usability is not important. It comes over as rather elitist.

Your posts remind me of typical Linux-on-the-desktop-defending posts that claim Linux's usability is just fine. Making X.org work isn't difficult, just run these 4 incomprehensible commands, edit this configuration file and insert this snippet for which you have to read a 50 page manual to understand. It's easy! What, can't do it? Then you're not deserving to use Linux, but Linux is oh so user friendly! (disclaimer: I love Linux, I want it to succeed on the desktop, but this kind of attitude is helping neither Linux nor Git)

You are reading things into my post that are not there. jamesgeck0 was arguing that every single user has to configure name/email, so this is clearly a "common" case. My counter-argument was that every single user has to configure this once. The common case is to be using git in its already-configured state.

What's more, most users are going to end up setting user/email as instructed via a tutorial before they even try to make their first commit. The case of someone trying to make a commit with zero configuration while not following a tutorial is a relatively exceptional case.

And you know what? The entire premise of the argument is flawed. I just tested. If user/email is not set up, git will infer your name and email from your username and hostname. It's almost certainly going to be wrong, but it'll let you continue on your merry way without giving the obscure error that was suggested.

Then have git output a message telling the user that the setting is now global. That way you accomodate for both cases in a usable manner.