5 ms·

GUM: A better CLI for Git

305 points by edave 15y ago

cleverjake 15y ago
There is no code on github https://github.com/saintsjd/gum https://github.com/saintsjd/gum but the idea sounds great!
- deleted 15y ago
  [deleted]
jmccaffrey 15y ago
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 get lost because it pretty closely matches the interface.
- hp 15y ago
  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.
zmanji 15y ago
Is it possible for all of these to be implemented as git command aliases?
- DrCatbox 15y ago
  Yes, this is what alias is for. You want a git unstage but cant remember what it was? Alias.
moe 15y ago
I think "git undo" would be even nicer if it was a generic undo and simply undid the last operation (only when possible of course; unpush might be slightly problematic). Also I'm really tired of messing with ~/.gitmodules and unwieldy *submodule-commands that demand to be executed in the project-root all the time. Why can't we simply "git add" sub-repositories, perhaps bailing with a warning by default and an extra-flag to really do it...
- akg 15y ago
  Agreed! Treating submodules as their own git repositories is a neat and powerful idea, but the UI really does breakdown. Especially when adding a trailing "/" to the submodule name like: 'git add submodule_name/' will assume you are deleting it and adding the files recursively in the parent project.
Groxx 15y ago
I quite like the idea, primarily because it would keep actions 'sounding like' what they affect. stage and unstage being the primary examples. Yeah, 'add' and 'reset' work, and fit other semantics, but when everything else refers to something you've added as something you've staged? Unnecessary cognitive friction. Add is largely useful for migrating from CVS/SVN/etc, but why not both with some porcelains? That said, take the time and learn what git does and how it works and it makes a ton of sense. It's remarkably simple, and then the commands map directly to what you're doing to your history, which is utterly fantastic.
acabal 15y ago
This is such a great idea. I'm using Git for my own repositories and I find myself doing searches for things like "how to undo a stage" or "how to revert a file" so often that it almost takes as much time to use Git as it does to do my programming. No doubt Git gods who have every nuance of the system memorized can take advantage of the flexibility of the (IMHO) complicated and obtuse CLI. But for schmucks like me who just want to get work done and not worry about it, something like this would be a godsend. I've more than once thought about switching away from Git just because I'm scared I'll do the wrong command and mess something up--and I've been programming for 15 years.
- dasil003 15y ago
  Not that the git UI doesn't leave a lot to be desired, but git has a nice security blanket: git reflog Now you can feel free rebase with abandon.
  - alexgartrell 15y ago
    git reflog is the SINGLE most undersold feature of get. It's a global, perpetual undo function (less garbage collection, which I understand to be discouraged).
  - barrybe 15y ago
    If you start depending on reflog just remember that changes in there are subject to garbage collection. Commits can be permanently deleted after they are 2 weeks old (by the default settings), so that's how long you can depend on them staying alive in the reflog. Of course you can always give a branch name or tag to any commit to keep it alive too.
    - angelbob 15y ago
      Two weeks isn't bad for an undo feature.
- masklinn 15y ago
  > No doubt Git gods who have every nuance of the system memorized can take advantage of the flexibility of the (IMHO) complicated and obtuse CLI. From what I understand, it's not even that. It's learning the plumbing. If you check the videos and presentations of the Github guys (mostly schacon), 90% of what he talks about are the implementation details of Git as an object store and the plumbing (the plumbing is the low-level commands dealing pretty directly with the repository's storage formats, porcelain is the set higher-level commands implemented in terms of plumbing). Why does he do that? Because the porcelain, git's high-level CLI, makes no sense in and of itself. It's inconsistent and weird and ugly and fraught with peril. But it makes sense in terms of the plumbing, if you know what happens "under the hood" you can make sense of porcelain commands: it remains dreadful, but now it's just a bunch of shortcuts for the sequences of low-level operations you know about. (as far as I'm concerned, I don't have the patience or the care for git's plumbing, so I just use hg and hg-git to interact with git repos)
matthewsnyder 15y ago
.gitconfig is your friend: https://gist.github.com/1706237 https://gist.github.com/1706237
- literalusername 15y ago
  That looks useful, but some comments would be nice. What do u, ud, and prep do?
  - matthewsnyder 15y ago
    `git u $branch` checks out $branch, updates it against whatever remote it's synced to, and then attempts to rebase the current branch against it. `git ud $branch` does the same think, except it also performs the merge of the current branch onto $branch. `git prep` Simply greps the commit for use of Python/JS print debugging statements, things that shouldn't make it into the codebase.
DrCatbox 15y ago
Where is this GUM or better cli for git? All I see is a README file containing the same thing as the webpost. Not to be a complainer, but there may be a reason the commands are the way they are and you cant simply change them without changing the implementation, perhaps you should look at alias to solve your memory problems.
- dholowiski 15y ago
  Is there a reason, or was this just the way the commands evolved? If there is a reason, this would be the perfect time to point it out. Otherwise, what's wrong with improving the UI for everone? [edit] but yeah, where's the code?
bryanp 15y ago
I've noticed that making the mental switch from writing code to committing it costs quite of bit of time throughout a day of development. A more intuitive interface would remove the need to make the mental switch. This interface feels much more intuitive to me -- great job.
beggi 15y ago
This is pretty nice. I totally concur with the post, and I think logical commands is the biggest (only?) benefit of Mercurial over Git... been using Legit by Kenneth Reitz lately... I recommend it highly https://github.com/kennethreitz/legit https://github.com/kennethreitz/legit
eridius 15y ago
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.
- mintplant 15y ago
  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.
blumentopf 15y ago
Why this is needed: Latest blog article over at progit.org: "Reset demystified" http://progit.org/2011/07/11/reset.html http://progit.org/2011/07/11/reset.html Scott Chacon, author of the the Pro Git book, admits there that he didn't cover the "reset" command in depth in the book because he didn't fully understand it. Go figure...
deleted 15y ago
[deleted]
chocolateboy 15y ago
This already exists. It's called EasyGit: http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/
- bryanlarsen 15y ago
  Note that the bottom of the above link also links to several other git porcelains designed for ease of use.
- hp 15y ago
  Elijah has a nice detailed breakdown of the EasyGit UI rationale as well: http://people.gnome.org/~newren/eg/git-eg-differences.html 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.
- dfabulich 15y ago
  It's criminal that more people don't know about/use EasyGit.
dave_sullivan 15y ago
I'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?
alwillis 15y ago
Such 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 http://www.ericsink.com/entries/hg_denzel.html.
freshlog 15y ago
Make this even more intuitive by wrapping git (or gum) in a REPL: https://github.com/defunkt/repl https://github.com/defunkt/repl I use this on a daily basis to avoid having to type "git" repetitively.
jsmcgd 15y ago
Can 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.
reinhardt 15y ago
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 coworkers) outweighs the occasional snafu.
- jrockway 15y ago
  Two things to remember about git: Once you commit something, you can always get it back via the reflog no matter what git commands you type. The second thing, you should expect to have to Google before every command if you want to understand any software in detail. It's like saying, "I refuse to learn to play the piano because I don't already know how to do it." Well, yes. Listen to the radio then, but don't whine about how the piano has a terrible design.
alinajaf 15y ago
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.
- rcthompson 15y ago
  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.
  - alinajaf 15y ago
    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.
    - rcthompson 15y ago
      Even if you just want to send a patch, in order to get the patch you need to run diff on the original file and the changed one. If you've already edited your copy, then in order to get a copy of the original you're back to either figuring out basic git usage or hoping that the source repo provides a web interface from which you can download it. Either way, without knowing how to use git the prospective contributor could easily get discouraged and give up.
phzbOx 15y ago
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.
davvid 15y ago
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/185825/focus=185863 http://thread.gmane.org/gmane.comp.version-control.git/18582... http://thread.gmane.org/gmane.comp.version-control.git/175061 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 --'`.
- falling 15y ago
  > 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.
  - nknight 15y ago
pjscott 15y ago
This is similar to what I get with magit-mode in emacs. It's pretty slick. http://philjackson.github.com/magit/ http://philjackson.github.com/magit/
- gnuvince 15y ago
  I've started using magit and I really like it; I like that I can just say "revert" on a file and magit knows what the right command is. Makes me think a whole lot less about Git and a whole lot more about my project.
- pbiggar 15y ago
  I came to post that. Magit has a very similar way of thinking about things, with commands being 'stage' and 'unstage' and a very simple revert, and nearly all commands work on chunks as well as on entire files. Nearly as much of a step up as using git was in the first place.
akkartik 15y ago
I recently discovered that creating a script called git_command somewhere in your path makes this work: $ git command Now these recommendations are easy to implement.
- JadeNB 15y ago
  Some experimentation suggests that it's actually `git-command` (with a hyphen, not an underscore). This is consistent with the man pages, where, for example, one asks for `man git-add`. EDIT: Not to take away from this handy tip, which I didn't know. I guess one can view it as a sort of souped-up alias.
  - akkartik 15y ago
    Oops, that was a typo.
ww520 15y ago
git status usually has a help command to unstage the change.
meemo 15y ago
I like the instructions in git status. I usually follow them when I'm not sure of what to do.
enobrev 15y ago
This is probably going to be a fairly unpopular opinion, since it seems git has won the popularity contest, but this is why I've always preferred bzr. Sure, it's a bit slower, but the interface is consistent. There aren't as many commands and they generally do the same thing every time. There aren't many switches on those commands either, besides the necessities, like defining revision numbers to apply the commands to. I started using git about 6 months ago, primarily for github, and it's obviously a very powerful tool. Unfortunately, all that time that is generally saved by git's speed gets sunk into browsing around trying to understand how to use it. I have about 15 git projects right now and I still have no idea how to do some of the simplest things with git. Maybe it's just because I came from years of svn, but I pretty much had bzr's interface figured out within a week. That whole week, I searched around for commands and whatnot and since then, it's been Incredibly rare for me to wonder what commands do what. I'm not saying you should switch, as git is certainly an incredible tool. But if you live your life in the CLI, I would recommend trying bzr out. The simple interface is a dream in comparison. Personally, if it weren't for github, I probably wouldn't use git at all for my own projects. That said, I may end up switching to git Because of github. And that's pretty much the only reason. Git's won the popularity contest an hence has a far larger ecosystem. But if I do make that switch, and that's a huge "if", I would miss bzr's CLI about as much as I miss childhood.
- shangaslammi 15y ago
  I absolutely agree with you. I used to use bzr for personal projects and compared to git it has way more intuitive commands and flags as well as smarter defaults. I use git nowadays mainly because of github and because it's what we use at work, but even after using git for two years I still need to constantly refer to the documentation for the various command flags.
- StavrosK 15y ago
  I used to use bzr too, then I switched to git because of the speed, and then to hg because git is impenetrable. Still, I miss bzr's ease of use and features (like any kind of branch you want). I don't know why it's not as popular, it certainly deserves to be. I've had more frustrations in my short stints with git and hg than I ever had with bzr, and I don't think it's just because I know it better. For example, hg just pops up a vimdiff window for updating and then just leaves me stranded in a place I still don't know when I :q it in fear. bzr just gave me three files, .base, .mine, .other and left me to do whatever I wanted with it and commit whenever I'm comfortable. I might just switch back to bzr again, I'm certainly losing more time now than I used to lose waiting for bzr to do its thing, and maybe it got faster now. About git, why not use bzr-git? It worked wonderfully when I was using it.
DannoHung 15y ago
All I want for git is a "git motd" command that teaches you a little bit of the plumbing every time you run it. And I will set it to execute when I login on a shell.
skrebbel 15y ago
I expected much more from this, off the title. Look, Git is a major pain in the ass because it's designed to support every possibly imaginable workflow. The only way to do this is to just expose Git's internals, i.e. make users think like Git, instead of making Git think like its users. This fits the minds of kernel hackers perfectly (they think like computers do all the time), so there's your history-of-Git in a one-liner as a free bonus. The only way to make Git more usable is to make a frontend that carefully and in a well thought out way enforces a certain workflow. It'll be more usable for people who use that workflow, then (and, obviously, less usable once you want to step outside that workflow) git-flow [1] is a nice example of this. I'd love to see more examples for additional workflows. I'm also very curious whether it's possible to do this without leaky abstractions, i.e. to really have a team up and running that doesn't understand anything about Git, and only understands the workflow. Did anyone using git flow manage that? (i.e. have devs never touch 'bare' git) [1][http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/]

305 points by edave 15y ago

cleverjake 15y ago

There is no code on github https://github.com/saintsjd/gum https://github.com/saintsjd/gum but the idea sounds great!

deleted 15y ago
[deleted]

jmccaffrey 15y ago

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 get lost because it pretty closely matches the interface.

hp 15y ago
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.

zmanji 15y ago

Is it possible for all of these to be implemented as git command aliases?

DrCatbox 15y ago
Yes, this is what alias is for. You want a git unstage but cant remember what it was? Alias.

moe 15y ago

I think "git undo" would be even nicer if it was a generic undo and simply undid the last operation (only when possible of course; unpush might be slightly problematic). Also I'm really tired of messing with ~/.gitmodules and unwieldy *submodule-commands that demand to be executed in the project-root all the time. Why can't we simply "git add" sub-repositories, perhaps bailing with a warning by default and an extra-flag to really do it...

akg 15y ago
Agreed! Treating submodules as their own git repositories is a neat and powerful idea, but the UI really does breakdown. Especially when adding a trailing "/" to the submodule name like: 'git add submodule_name/' will assume you are deleting it and adding the files recursively in the parent project.

Groxx 15y ago

I quite like the idea, primarily because it would keep actions 'sounding like' what they affect. stage and unstage being the primary examples. Yeah, 'add' and 'reset' work, and fit other semantics, but when everything else refers to something you've added as something you've staged? Unnecessary cognitive friction. Add is largely useful for migrating from CVS/SVN/etc, but why not both with some porcelains? That said, take the time and learn what git does and how it works and it makes a ton of sense. It's remarkably simple, and then the commands map directly to what you're doing to your history, which is utterly fantastic.

acabal 15y ago

This is such a great idea. I'm using Git for my own repositories and I find myself doing searches for things like "how to undo a stage" or "how to revert a file" so often that it almost takes as much time to use Git as it does to do my programming. No doubt Git gods who have every nuance of the system memorized can take advantage of the flexibility of the (IMHO) complicated and obtuse CLI. But for schmucks like me who just want to get work done and not worry about it, something like this would be a godsend. I've more than once thought about switching away from Git just because I'm scared I'll do the wrong command and mess something up--and I've been programming for 15 years.

dasil003 15y ago
Not that the git UI doesn't leave a lot to be desired, but git has a nice security blanket: git reflog Now you can feel free rebase with abandon.
- alexgartrell 15y ago
  git reflog is the SINGLE most undersold feature of get. It's a global, perpetual undo function (less garbage collection, which I understand to be discouraged).
- barrybe 15y ago
  If you start depending on reflog just remember that changes in there are subject to garbage collection. Commits can be permanently deleted after they are 2 weeks old (by the default settings), so that's how long you can depend on them staying alive in the reflog. Of course you can always give a branch name or tag to any commit to keep it alive too.
  - angelbob 15y ago
    Two weeks isn't bad for an undo feature.
masklinn 15y ago
> No doubt Git gods who have every nuance of the system memorized can take advantage of the flexibility of the (IMHO) complicated and obtuse CLI. From what I understand, it's not even that. It's learning the plumbing. If you check the videos and presentations of the Github guys (mostly schacon), 90% of what he talks about are the implementation details of Git as an object store and the plumbing (the plumbing is the low-level commands dealing pretty directly with the repository's storage formats, porcelain is the set higher-level commands implemented in terms of plumbing). Why does he do that? Because the porcelain, git's high-level CLI, makes no sense in and of itself. It's inconsistent and weird and ugly and fraught with peril. But it makes sense in terms of the plumbing, if you know what happens "under the hood" you can make sense of porcelain commands: it remains dreadful, but now it's just a bunch of shortcuts for the sequences of low-level operations you know about. (as far as I'm concerned, I don't have the patience or the care for git's plumbing, so I just use hg and hg-git to interact with git repos)

matthewsnyder 15y ago

.gitconfig is your friend: https://gist.github.com/1706237 https://gist.github.com/1706237

literalusername 15y ago
That looks useful, but some comments would be nice. What do u, ud, and prep do?
- matthewsnyder 15y ago
  `git u $branch` checks out $branch, updates it against whatever remote it's synced to, and then attempts to rebase the current branch against it. `git ud $branch` does the same think, except it also performs the merge of the current branch onto $branch. `git prep` Simply greps the commit for use of Python/JS print debugging statements, things that shouldn't make it into the codebase.

DrCatbox 15y ago

Where is this GUM or better cli for git? All I see is a README file containing the same thing as the webpost. Not to be a complainer, but there may be a reason the commands are the way they are and you cant simply change them without changing the implementation, perhaps you should look at alias to solve your memory problems.

dholowiski 15y ago
Is there a reason, or was this just the way the commands evolved? If there is a reason, this would be the perfect time to point it out. Otherwise, what's wrong with improving the UI for everone? [edit] but yeah, where's the code?

bryanp 15y ago

I've noticed that making the mental switch from writing code to committing it costs quite of bit of time throughout a day of development. A more intuitive interface would remove the need to make the mental switch. This interface feels much more intuitive to me -- great job.

beggi 15y ago

This is pretty nice. I totally concur with the post, and I think logical commands is the biggest (only?) benefit of Mercurial over Git... been using Legit by Kenneth Reitz lately... I recommend it highly https://github.com/kennethreitz/legit https://github.com/kennethreitz/legit

eridius 15y ago

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.

mintplant 15y ago
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.

blumentopf 15y ago

Why this is needed: Latest blog article over at progit.org: "Reset demystified" http://progit.org/2011/07/11/reset.html http://progit.org/2011/07/11/reset.html Scott Chacon, author of the the Pro Git book, admits there that he didn't cover the "reset" command in depth in the book because he didn't fully understand it. Go figure...

deleted 15y ago

[deleted]

chocolateboy 15y ago

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

bryanlarsen 15y ago
Note that the bottom of the above link also links to several other git porcelains designed for ease of use.
hp 15y ago
Elijah has a nice detailed breakdown of the EasyGit UI rationale as well: http://people.gnome.org/~newren/eg/git-eg-differences.html 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.
dfabulich 15y ago
It's criminal that more people don't know about/use EasyGit.

dave_sullivan 15y ago

I'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?

alwillis 15y ago

Such 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 http://www.ericsink.com/entries/hg_denzel.html.

freshlog 15y ago

Make this even more intuitive by wrapping git (or gum) in a REPL: https://github.com/defunkt/repl https://github.com/defunkt/repl I use this on a daily basis to avoid having to type "git" repetitively.

jsmcgd 15y ago

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

reinhardt 15y ago

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 coworkers) outweighs the occasional snafu.

jrockway 15y ago
Two things to remember about git: Once you commit something, you can always get it back via the reflog no matter what git commands you type. The second thing, you should expect to have to Google before every command if you want to understand any software in detail. It's like saying, "I refuse to learn to play the piano because I don't already know how to do it." Well, yes. Listen to the radio then, but don't whine about how the piano has a terrible design.

alinajaf 15y ago

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.

rcthompson 15y ago
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.
- alinajaf 15y ago
  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.
  - rcthompson 15y ago
    Even if you just want to send a patch, in order to get the patch you need to run diff on the original file and the changed one. If you've already edited your copy, then in order to get a copy of the original you're back to either figuring out basic git usage or hoping that the source repo provides a web interface from which you can download it. Either way, without knowing how to use git the prospective contributor could easily get discouraged and give up.

phzbOx 15y ago

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.

davvid 15y ago

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/185825/focus=185863 http://thread.gmane.org/gmane.comp.version-control.git/18582... http://thread.gmane.org/gmane.comp.version-control.git/175061 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 --'`.

falling 15y ago
> 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.
- nknight 15y ago

pjscott 15y ago

This is similar to what I get with magit-mode in emacs. It's pretty slick. http://philjackson.github.com/magit/ http://philjackson.github.com/magit/

gnuvince 15y ago
I've started using magit and I really like it; I like that I can just say "revert" on a file and magit knows what the right command is. Makes me think a whole lot less about Git and a whole lot more about my project.
pbiggar 15y ago
I came to post that. Magit has a very similar way of thinking about things, with commands being 'stage' and 'unstage' and a very simple revert, and nearly all commands work on chunks as well as on entire files. Nearly as much of a step up as using git was in the first place.

akkartik 15y ago

I recently discovered that creating a script called git_command somewhere in your path makes this work: $ git command Now these recommendations are easy to implement.

JadeNB 15y ago
Some experimentation suggests that it's actually `git-command` (with a hyphen, not an underscore). This is consistent with the man pages, where, for example, one asks for `man git-add`. EDIT: Not to take away from this handy tip, which I didn't know. I guess one can view it as a sort of souped-up alias.
- akkartik 15y ago
  Oops, that was a typo.

ww520 15y ago

git status usually has a help command to unstage the change.

meemo 15y ago

I like the instructions in git status. I usually follow them when I'm not sure of what to do.

enobrev 15y ago

This is probably going to be a fairly unpopular opinion, since it seems git has won the popularity contest, but this is why I've always preferred bzr. Sure, it's a bit slower, but the interface is consistent. There aren't as many commands and they generally do the same thing every time. There aren't many switches on those commands either, besides the necessities, like defining revision numbers to apply the commands to. I started using git about 6 months ago, primarily for github, and it's obviously a very powerful tool. Unfortunately, all that time that is generally saved by git's speed gets sunk into browsing around trying to understand how to use it. I have about 15 git projects right now and I still have no idea how to do some of the simplest things with git. Maybe it's just because I came from years of svn, but I pretty much had bzr's interface figured out within a week. That whole week, I searched around for commands and whatnot and since then, it's been Incredibly rare for me to wonder what commands do what. I'm not saying you should switch, as git is certainly an incredible tool. But if you live your life in the CLI, I would recommend trying bzr out. The simple interface is a dream in comparison. Personally, if it weren't for github, I probably wouldn't use git at all for my own projects. That said, I may end up switching to git Because of github. And that's pretty much the only reason. Git's won the popularity contest an hence has a far larger ecosystem. But if I do make that switch, and that's a huge "if", I would miss bzr's CLI about as much as I miss childhood.

shangaslammi 15y ago
I absolutely agree with you. I used to use bzr for personal projects and compared to git it has way more intuitive commands and flags as well as smarter defaults. I use git nowadays mainly because of github and because it's what we use at work, but even after using git for two years I still need to constantly refer to the documentation for the various command flags.
StavrosK 15y ago
I used to use bzr too, then I switched to git because of the speed, and then to hg because git is impenetrable. Still, I miss bzr's ease of use and features (like any kind of branch you want). I don't know why it's not as popular, it certainly deserves to be. I've had more frustrations in my short stints with git and hg than I ever had with bzr, and I don't think it's just because I know it better. For example, hg just pops up a vimdiff window for updating and then just leaves me stranded in a place I still don't know when I :q it in fear. bzr just gave me three files, .base, .mine, .other and left me to do whatever I wanted with it and commit whenever I'm comfortable. I might just switch back to bzr again, I'm certainly losing more time now than I used to lose waiting for bzr to do its thing, and maybe it got faster now. About git, why not use bzr-git? It worked wonderfully when I was using it.

DannoHung 15y ago

All I want for git is a "git motd" command that teaches you a little bit of the plumbing every time you run it. And I will set it to execute when I login on a shell.

skrebbel 15y ago

I expected much more from this, off the title. Look, Git is a major pain in the ass because it's designed to support every possibly imaginable workflow. The only way to do this is to just expose Git's internals, i.e. make users think like Git, instead of making Git think like its users. This fits the minds of kernel hackers perfectly (they think like computers do all the time), so there's your history-of-Git in a one-liner as a free bonus. The only way to make Git more usable is to make a frontend that carefully and in a well thought out way enforces a certain workflow. It'll be more usable for people who use that workflow, then (and, obviously, less usable once you want to step outside that workflow) git-flow [1] is a nice example of this. I'd love to see more examples for additional workflows. I'm also very curious whether it's possible to do this without leaky abstractions, i.e. to really have a team up and running that doesn't understand anything about Git, and only understands the workflow. Did anyone using git flow manage that? (i.e. have devs never touch 'bare' git) [1][http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/]