This already exists. It's called EasyGit:
GUM: A better CLI for Git
31–40 of 85 posts
Re: GUM: A better CLI for Git
#32This already exists. It's called EasyGit: http://people.gnome.org/~newren/eg/
Note that the bottom of the above link also links to several other git porcelains designed for ease of use.
Re: GUM: A better CLI for Git
#33Earlier quoted context omitted.
>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 pe…
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.
Re: GUM: A better CLI for Git
#34I've seen a few "better CLI for X" applications lately, I think there might be something there. Personally, I almost prefer cli at this point for lots of stuff, but a lot of it is still just so cryptic. It doesn't need to be.
Thinking about usability doesn't have to be limited to web apps, and it's refreshing to see some people starting to agree.
Edit: definitely not sure where a business would be for a product like that, such a niche market, and a market that doesn't like paying for things. But who knows?
Re: GUM: A better CLI for Git
#35Earlier quoted context omitted.
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 pe…
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…
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.
Re: GUM: A better CLI for Git
#36Such a good idea. I mostly use Mercurial, which has a clean, logical and consistent CLI which I like a lot. And while I like the concept of Git, using it makes my head hurt.
I'm reminded of the article that compares the two: Git is Wesley Snipes; Mercurial is Denzel Washington: http://www.ericsink.com/entries/hg_denzel.html.
Re: GUM: A better CLI for Git
#37Make this even more intuitive by wrapping git (or gum) in a REPL:
https://github.com/defunkt/repl
I use this on a daily basis to avoid having to type "git" repetitively.
Re: GUM: A better CLI for Git
#38Earlier quoted context omitted.
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…
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.
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.
Re: GUM: A better CLI for Git
#39Can I suggest that 'select' is used instead of 'stage'? After all, one is just selecting the files to be committed. Staging, although a legitimate use of the word, is a bit abstract I feel. I can't imagine anyone failing to understand the concept of selecting something.
Re: GUM: A better CLI for Git
#40Cool, I might try this to give Git a second chance, for now I am resorting to hg-git whenever I have to touch a git project. Sometimes it gets confused when I'm rewriting history on the hg side and pull from the git upstream but overall having a sane UI I feel confident about without googling before every command (or worse, limiting myself to a "safe" subset and using it almost like Subversion, as some of my coworkers) outweighs the occasional snafu.