[eridius]

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.

[jamesgeck0]

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.

[eridius]

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.

[asomiv]

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.

[jamesgeck0]

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.

[eridius]

If the user needs the prompt to be able to set up user/email, then they're probably not qualified to diagnose what went wrong with their setup if something does go wrong. This way they can get help and fix whatever actually went wrong, rather than just re-setting their username/email and then discovering later that they lost all of their other configuration too.

Users that are capable of diagnosing what went wrong with their repo are also comfortable setting username/email in the config.

[Zev]

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.

[eridius]

You seem confused. If you want a pretty UI, what the hell are you doing on the command line? Go grab one of the half-dozen Git GUI apps out there. There's a few decent ones out these days, and they'll handle things like setting up your name/email.

[eridius]

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.

[asomiv]

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)

[eridius]

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.

[asomiv]

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.