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

81–85 of 85 posts

Re: GUM: A better CLI for Git

#81

Post by Symmetry »

exDM69 wrote: post #79
acabal wrote: post #7

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

> 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. There are no git gods. They are just mere mortals who read the manual and look divine in the eyes of fools.

Did you read the OP? He wasn't complaining about being unable to find the right commands, he was complaining about being unable to remember the right commands after having found them, because they're so obtuse.

Re: GUM: A better CLI for Git

#82

Post by nknight »

falling wrote: post #50
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 dif…

> To me, git feels like building blocks that you use to create your own versioning system and workflow

That's because it is almost exactly that. It helps to go back and read the earliest discussions of it.

Linus didn't build a version control system. He never really intended to. He built "gitfs" and equivalents of mkfs, fsck, cd, rm, mv, cp, and a thousand other tools for manipulating it.

Unfortunately, they were also built rather specifically to Linus's mental model and the kernel's workflow, so they look pretty funny to everyone else.

It's getting better. The git of 2012 is a lot friendlier than the git of 2005. But the impedance mismatch between what Linus was building and what the rest of the world expects is a long way from being eliminated.

Re: GUM: A better CLI for Git

#83

Post by StavrosK »

enobrev wrote: post #80
StavrosK wrote: post #78

Earlier quoted context omitted.

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

I started out with bzr-git a long time ago for small one-off projects where I wasn't getting too deep into the process. Well, that's not true, when I First dug into DVCS, I tried all three, and since I was on windows back then (all-linux, now), git failed early, as since it didn't have a native windows version. Later on, when I didn't necessarily have time to learn git due to short deadlines, I tried bzr-git a few ti…

Well, I prefer to work in vim, so the speed with which my VCS does things is pretty important. Other than that, screw it, I just switched back to bzr. Both hg and bzr have very good git interoperability, so now I can use whichever of the three VCSes I like, even for the same working tree (I can have .git, .hg and .bzr in the same working tree, all updated, and push whichever I like).

I'm already enjoying bzr again, though. I also would like to learn git, but I have a startup to launch, and I don't think git is worth the (pretty big) effort at this stage.

Re: GUM: A better CLI for Git

#84

Post by JadeNB »

akkartik wrote: post #52

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.

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.

Re: GUM: A better CLI for Git

#85

Post by akkartik »

JadeNB wrote: post #84
akkartik wrote: post #52

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.

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.

Oops, that was a typo.
Post reply on HN