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

21–30 of 85 posts

Re: GUM: A better CLI for Git

#21

Post by jamesgeck0 »

eridius wrote: post #16

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

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

Re: GUM: A better CLI for Git

#22

Post by [deleted] »

eridius wrote: post #18
mintplant wrote: post #17

Earlier quoted context omitted.

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.

Interesting idea, though I don't get the need for the --revision flag in your example. It's already pretty easy to tell the difference between revisions and files. If you want to call it unwind, why not just make that an alias for reset? git config alias.rewind reset

[deleted]

Re: GUM: A better CLI for Git

#23

Post by [deleted] »

eridius wrote: post #18
mintplant wrote: post #17

Earlier quoted context omitted.

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.

Interesting idea, though I don't get the need for the --revision flag in your example. It's already pretty easy to tell the difference between revisions and files. If you want to call it unwind, why not just make that an alias for reset? git config alias.rewind reset

[deleted]

Re: GUM: A better CLI for Git

#25

Post by mintplant »

eridius wrote: post #18
mintplant wrote: post #17

Earlier quoted context omitted.

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.

Interesting idea, though I don't get the need for the --revision flag in your example. It's already pretty easy to tell the difference between revisions and files. If you want to call it unwind, why not just make that an alias for reset? git config alias.rewind reset

Ah, okay. Wasn't sure how well the system could differentiate the two.

You could always make aliases for things, but the point of the article seems to be addressing the problem of people new to git, who likely won't go about setting such aliases, let alone know they have that capability.

And that's a problem I can sympathize with: I'm a programmer on an FRC (http://www.usfirst.org/) team, and this year, we finally convinced everyone to make the jump from a thousand USB sticks to a git repo. We've held a workshop on it and have distributed various tutorials -- GitHub's have been particularly invaluable -- but there are still issues every now and again. Some seem to only have "push button, receive outcome" understanding of how it works, memorizing the commands for cloning, pushing, and pulling and then blindly repeating them into the console, without a full knowledge of what's going on. If some of the more "advanced" syntax was a bit more human from the get-go, then it might be helpful in softening the learning curve.

Re: GUM: A better CLI for Git

#26

Post by barrybe »

dasil003 wrote: post #13
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…

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.

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.

Re: GUM: A better CLI for Git

#28

Post by matthewsnyder »

literalusername wrote: post #24
matthewsnyder wrote: post #8

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

That looks useful, but some comments would be nice. What do u, ud, and prep do?

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

Re: GUM: A better CLI for Git

#29

Post by eridius »

jamesgeck0 wrote: post #21
eridius wrote: post #16

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

>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 perfectly justified in blaming git's faulty user interface for letting that happen. At least if I set the config myself I _know_ I'm placing it in the global config file.
Post reply on HN