GUM: A better CLI for Git

Post by eridius » Mon, Jan 30, 2012, 11:47 PM UTC

Zev wrote: post #48

eridius wrote: post #42

Earlier quoted context omitted.

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 wi…

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…

Post by jrockway » Tue, Jan 31, 2012, 12:04 AM UTC

reinhardt wrote: post #40

Cool, 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 coworker…

Post by alinajaf » Tue, Jan 31, 2012, 12:53 AM UTC

rcthompson wrote: post #45

alinajaf wrote: post #41

I'm going to put my grumpy old man hat on for a second and say that if you don't understand how git works, then you shouldn't be using it. Go use svn or hg or something that has a simpler internal model, and good luck to you. For me, gits internal model is simply not that hard, and I'm a run of the mill twenty-something year old developer who feels vaguely guilty about not knowing how fundamental data structures and…

I can appreciate the sentiment that Git's internal model is straightforward enough that the UI is justified in exposing it. However, you also have to consider the perspective of someone who sees a cool project, decides to contribute code, sees that that the project code is in a git repo, and says, "Ok, I'll learn the basics of git so I can contribute to this cool project." It's not fair to expect such a person to lea…

Post by eridius » Tue, Jan 31, 2012, 1:20 AM UTC

eridius wrote: post #35

jamesgeck0 wrote: post #33

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

Post by rcthompson » Tue, Jan 31, 2012, 1:25 AM UTC

alinajaf wrote: post #55

rcthompson wrote: post #45

Earlier quoted context omitted.

I can appreciate the sentiment that Git's internal model is straightforward enough that the UI is justified in exposing it. However, you also have to consider the perspective of someone who sees a cool project, decides to contribute code, sees that that the project code is in a git repo, and says, "Ok, I'll learn the basics of git so I can contribute to this cool project." It's not fair to expect such a person to lea…

In that particular case, I'd be inclined to send over the patch as a diff file, though I can see the point your making.