Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GUM: A better CLI for Git

saintsjd.com

Post reply on HN
Print view View original

41–50 of 85 posts

Re: GUM: A better CLI for Git

#41

Post by alinajaf »

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 algorithms work. It's a directed acyclic graph that points to items in a content addressable database. Between the progit book and the man pages, I had a pretty good conceptual model of it in an afternoon. I encourage anyone who actually wants to learn it to spend a little time with TFM and get it out of the way.

Otherwise, seriously, quit your whining. The CLI makes intuitive sense to me and I can manipulate the DAG without much mental effort. The worst case scenario is that you rebase public history, and `git help rebase` will tell you how to get yourself out of that mess.

Re: GUM: A better CLI for Git

#42

Post by eridius »

jamesgeck0 wrote: post #38
eridius wrote: post #35

Earlier quoted context omitted.

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.

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.

Re: GUM: A better CLI for Git

#43

Post by phzbOx »

One problem of that thought it that it will make git commands even more obscure. I.e. when a user will have to use the real git cli, they will be totally lost. I'm not saying it's a bad idea, just something to think about when designing the new cli. Maybe try to stay consistent with the commands while still making them easier to remember and understand. For instance:

  git diff STAGE HEAD
seems a bit unconventional to me.

Re: GUM: A better CLI for Git

#44

Post by hp »

chocolateboy wrote: post #31

This already exists. It's called EasyGit: http://people.gnome.org/~newren/eg/

Elijah has a nice detailed breakdown of the EasyGit UI rationale as well: http://people.gnome.org/~newren/eg/git-eg-differences.html

I've been using EasyGit for years, it's very good and addresses exactly the complaint made in this article. Plus it's a one-file script so it's simple to drop it onto whatever computer you're using.

Re: GUM: A better CLI for Git

#45

Post by rcthompson »

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 learn the whole data model of git and how all the commands map to it just so they can contribute a 5-line patch in the project's native VCS. So I think there's definitely a strong argument in favor of providing a porcelain for Git that is independent of its plumbing, even if that porcelain is only capable of some basic operations.

Re: GUM: A better CLI for Git

#46

Post by hp »

jmccaffrey wrote: post #3

I'm not sure I agree that it's necessarily bad if the interface is a side-effect of the implementation. It seems very worse-is-better to me. I feel like when the interface is a side-effect of implementation, you get a more gradual sliding scale from user to developer (like being able to experiment with web apis by curling at them). In git's case, I appreciate that I can trawl around through my .git directory and not…

That said, I'm not sure UI matching the implementation is the problem with git's UI; it's more that git's UI is inconsistent, has poorly-chosen names for commands/options, and has bad default behaviors.

Re: GUM: A better CLI for Git

#47

Post by davvid »

While this may be a nice idea, I don't know if it improves the situation. Improving the situation means tackling the entire problem, top-to-bottom.

http://thread.gmane.org/gmane.comp.version-control.git/18582...

http://thread.gmane.org/gmane.comp.version-control.git/17506...

Quoting Junio, the git maintainer:

"""Rc or not rc, just repeating a fuzzy and uncooked "idea" around phoney ref-looking names that will end up confusing the users, and selling that as if it is a logical conclusion to "we want to give an easier to understand UI", without presenting a solid user experience design that is convincing enough that the "idea" will reduce confusion will not get us anywhere"""

Here's the first example from the blog post:

    # Why not replace things like: git reset HEAD -- file with:
    > git unstage
What the author fails to realize is that you could have just said, "git reset file", which makes this `unstage` example much less convincing.

We actually do not recommend `git reset --hard` very often these days. `git checkout -f` is nicer alternative and is semantically related to `git checkout file`.

The 'stage' alias that adds and also understands deletions is a nice addition. It can be implemented as an alias. `git config --global alias.stage 'add -u --'`.

Re: GUM: A better CLI for Git

#48

Post by Zev »

eridius wrote: post #42
jamesgeck0 wrote: post #38

Earlier quoted context omitted.

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.

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 ~/.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.

Re: GUM: A better CLI for Git

#50

Post by falling »

davvid wrote: post #47

While this may be a nice idea, I don't know if it improves the situation. Improving the situation means tackling the entire problem, top-to-bottom. http://thread.gmane.org/gmane.comp.version-control.git/18582... http://thread.gmane.org/gmane.comp.version-control.git/17506... Quoting Junio, the git maintainer: """Rc or not rc, just repeating a fuzzy and uncooked "idea" around phoney ref-looking names that will end up…

> While this may be a nice idea, I don't know if it improves the situation. Improving the situation means tackling the entire problem, top-to-bottom.

First you have to define the problem.

To me, git feels like building blocks that you use to create your own versioning system and workflow: you learn the tool, you discover which features are useful to you and you use only those. Another person (or group) will use a different process and a different set of features, effectively creating a different version control system.

So, in my opinion, git tackles the problem of being the foundation to a wide range of different VCSs, and does a pretty good job at that.

Something like this is tackling a similar problem to git-flow. Tools like this, with less features but that define or suggest a workflow are very useful, because they remove the confusion while you learn the tool and try to create your workflow at the same time, without knowing what the tool can do for you.

Post reply on HN