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:
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.
>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?
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.
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.
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.
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.
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.
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.
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 stage
git unstage 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
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: though I rarely use the `git unstaged` command. I also have 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.