[eridius]

Most of this stuff can be done with aliases.

git stage

  git config alias.stage '!f () { if (( $# > 0 )); then git add -- "$@"; else git add -u; fi }; f'
  

git unstage

  git config alias.unstage 'reset --'
  

git undo is too ill-defind to actually implement. Sounds like the author wants it to be `git reset --hard HEAD`, but it's far more dangerous doing that while termed `git undo` than it is while termed `git reset --hard HEAD`, because people will have unrealistic expectations of what it does.

What's wrong with `git rm`? Here's a hint: you don't need to use it. Most people I know just delete the files however they want, and then run something like `git add -u` to pick up the deletions. That's exactly what the author is suggesting, but that's what people do today, so I don't see the issue.

As for git status, there's already a --short (or -s) flag that gives a very terse output. I personally use that all the time with an alias `git config alias.st 'status -sb'`.

Automatic setup? Put that info in the global config file. If git had to prompt for it, it would naturally place that info in the per-repo config file (absolutely would not make sense to automatically modify the global one), and it would be more confusing to users to be constantly re-prompted for name/email (because they switched repos). I don't see the problem with just telling new users to set up name/email globally, which every git tutorial I've seen does.

git switch

  git config alias.switch checkout

For git diff confusion, just use aliases for different commands. Do not make me type STAGE, that's no friendlier to users. I personally run with the following two aliases:

  git config alias.staged 'diff --cached'
  git config alias.unstaged 'diff'

though I rarely use the `git unstaged` command. I also have

  git config alias.both 'diff HEAD'

though I never use this one. Perhaps other names can be chosen that the author likes better.

The bit about deleting branches is misguided. `git remote` is a command that has sub-commands. `git branch` isn't. I understand that the author thinks having two styles of commands is weird, but there's not really a good alternative. Commands like `git remote` that have sub-commands would not work very well at all in the switch model (for a pathalogical example try to imagine what `git svn` would look like this way), and switch-based commands, which is most commands in git (and most commands in UNIX in general) would not do well in the sub-command model.

[jamesgeck0]

>Automatic setup? Put that info in the global config file. If git had to prompt for it, it would naturally place that info in the per-repo config file (absolutely would not make sense to automatically modify the global one)

You're thinking of implementation details, but prompting for and placing the info into ~/.gitconfig is what a newbie git user almost always wants. What's wrong with doing this?

[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.

[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)

[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.

[mintplant]

Per "git undo", what about something like:

    git rewind
    git rewind FILE
    
    git rewind --revision=REVISION
    git rewind FILE --revision=REVISION

We already have the "fast forward" metaphor.

[eridius]

Interesting idea, though I don't get the need for the --revision flag in your example. It's already pretty easy to tell the difference between revisions and files. If you want to call it unwind, why not just make that an alias for reset?

  git config alias.rewind reset