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

71–80 of 85 posts

Re: GUM: A better CLI for Git

#71

Post by asomiv »

eridius wrote: post #35
jamesgeck0 wrote: post #33

Earlier quoted context omitted.

Your use case makes sense, but 1) Git's current initial setup UI would not prevent the user from making that mistake. It might make them feel stupid when they remember, but that's not the same thing as usability. The commit interface displays your identity and might throw up a red light. 2) Having made this mistake, a new user isn't going to remember the "git config" or "git commit --amend" commands they copied when…

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.

I dispute this claim. There are only very few ways your ~/.gitconfig can be corrupted:

1. You edited it by hand and fucked up the syntax. In this case git could print an error instead if offering to add the username/email.

2. You deleted itself. When git asks you for the username/email again it'll actually tell you that that file was for storing the username/email.

3. Filesystem error. A faulty gitconfig with be the last thing the user is worrying about.

All in all I don't see how all of this would imply that prompting a username/email isn't a good idea.

Re: GUM: A better CLI for Git

#72

Post by asomiv »

eridius wrote: post #29
jamesgeck0 wrote: post #21

Earlier quoted context omitted.

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

Then have git output a message telling the user that the setting is now global. That way you accomodate for both cases in a usable manner.

Re: GUM: A better CLI for Git

#73

Post by e_proxus »

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…

But I'm not using git so I have to understand how a RCS works, I'm using git so I can keep track of my files!

Similarly, you don't program C just so you have to learn assembler and how a CPU works. Yes, if you do you can do awesome things, but that's not the point, that's a bonus.

Re: GUM: A better CLI for Git

#74

Post by akg »

moe wrote: post #5

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

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.

Re: GUM: A better CLI for Git

#75

Post by skrebbel »

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/]

Re: GUM: A better CLI for Git

#76

Post by eridius »

asomiv wrote: post #70
eridius wrote: post #57

Earlier quoted context omitted.

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

You are reading things into my post that are not there. jamesgeck0 was arguing that every single user has to configure name/email, so this is clearly a "common" case. My counter-argument was that every single user has to configure this once. The common case is to be using git in its already-configured state.

What's more, most users are going to end up setting user/email as instructed via a tutorial before they even try to make their first commit. The case of someone trying to make a commit with zero configuration while not following a tutorial is a relatively exceptional case.

And you know what? The entire premise of the argument is flawed. I just tested. If user/email is not set up, git will infer your name and email from your username and hostname. It's almost certainly going to be wrong, but it'll let you continue on your merry way without giving the obscure error that was suggested.

Re: GUM: A better CLI for Git

#77

Post by eridius »

sanderjd wrote: post #67
eridius wrote: post #58

Earlier quoted context omitted.

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

Did you even read the OP? There is no tool. It's a blog post with a wish list for a magical tool that the author wants someone to create. Try reading the article next time before you go argue in the comments.

Re: GUM: A better CLI for Git

#78

Post by StavrosK »

enobrev wrote: post #63

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

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.

Re: GUM: A better CLI for Git

#79

Post by exDM69 »

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.

Re: GUM: A better CLI for Git

#80

Post by enobrev »

StavrosK wrote: post #78
enobrev wrote: post #63

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

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

I don't have _real_ answer, besides that it doesn't "feel right" to use another tool on a git repo. I _want_ to know git better. It's just not very easy to learn without fully committing to it.

As for bzr, there have definitely been speed improvements in the past couple years. I can't say how much faster, as I'm used to it. The Only times I notice things running slowly are when branching a large remote repo for the first time and when my system is completely maxed (currently working on a dynamic video-generation project). Otherwise, I barely notice. And besides, how often does one actually wait for a return prompt when checking in? `bzr ci -m "whatever"` and alt-tab back to whatever I'm working on.

* editing for clarification

Post reply on HN