I like the instructions in git status. I usually follow them when I'm not sure of what to do.
GUM: A better CLI for Git
61–70 of 85 posts
Re: GUM: A better CLI for Git
#62This is similar to what I get with magit-mode in emacs. It's pretty slick. http://philjackson.github.com/magit/
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.
Re: GUM: A better CLI for Git
#63This 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.
Re: GUM: A better CLI for Git
#64This is similar to what I get with magit-mode in emacs. It's pretty slick. http://philjackson.github.com/magit/
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.
Re: GUM: A better CLI for Git
#65Earlier quoted context omitted.
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.
Two weeks isn't bad for an undo feature.
Re: GUM: A better CLI for Git
#66All 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.
Re: GUM: A better CLI for Git
#67Earlier quoted context omitted.
Where's this rule that just because it is text based means that it has to be ugly? I seem to have missed the memo on it.
You're arguing in favor of having a "pretty UI" _at the expense_ of functionality. That's absolutely inappropriate for a command-line tool, especially one that was originally designed for use by hard-core computer programmers. If you want a pretty UI, go use a tool that wraps Git and provides one, like I just suggested. Sure, if you want to suggest that Git's error upon not having a username/email is made a bit frien…
Here is how I read this thread - someone links to a tool that wraps git with a prettier command line UI, you say that you don't need that, here's some magical aliases, others say but those aren't pretty like the tool we were originally discussing, you say "if you want a pretty UI, go use a tool that wraps Git and provides one" ...like the one from the original link? I don't get your argument, is there a reasonable place for prettier UIs wrapping common Git commands, or do we all just need to be more hardcore and learn to write good aliases?
Re: GUM: A better CLI for Git
#68This already exists. It's called EasyGit: http://people.gnome.org/~newren/eg/
It's criminal that more people don't know about/use EasyGit.
Re: GUM: A better CLI for Git
#69This 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 t…
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.
Re: GUM: A better CLI for Git
#70Earlier 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.
Can you folks who are downvoting me please tell me _why_ you are doing this? We're not on reddit. What I posted is absolutely not deserving of downvotes. If you disagree with me, post a reply.
I'm not the guy who voted you down, but I'm guessing other people did it because your posts' attitude imply that new users are absolutely not worth accommodating for and that usability is not important. It comes over as rather elitist.
Your posts remind me of typical Linux-on-the-desktop-defending posts that claim Linux's usability is just fine. Making X.org work isn't difficult, just run these 4 incomprehensible commands, edit this configuration file and insert this snippet for which you have to read a 50 page manual to understand. It's easy! What, can't do it? Then you're not deserving to use Linux, but Linux is oh so user friendly! (disclaimer: I love Linux, I want it to succeed on the desktop, but this kind of attitude is helping neither Linux nor Git)