Hacker News Reader

Comment by aninteger | Hacker News Reader

Regarding the "A Sane Command Line Interface" topic. Linus mentioned in his talk at Google about Git that he often chose the opposite approach to do things rather than follow the Subversion approach. This might be why the commands are not named the same as Subversion commands.

git add/rm handles making changes to the index and there is no similar concept in mercurial or subversion.

View on HN

I think this is not only about similarity. For example, branching works with `git branch foo`, but it doesn't immediately switch to that branch. If you want to do this, `git checkout -b foo` is the way to go. While this might make some sense if you understand the details behind git, it is horrible from a user interface perspective. I know a lot of people that didn't know about checkout -b because they never thought about looking there.

Also, some features are half-implemented, for example `git add -p` which does not trigger on file-additions (and sometimes is broke out of the box on some distros).

I like git, but the interface: not so much. Too many rough edges.

The blog post does not illustrate this, though :/.

Update: and for the downvotes, would you care to explain why?

I'm not downvoting you but the git branch command is orthogonal to checking out a branch. The branch command adds, removes and lists branches. The checkout command switches between them. There is a convenience command that does a checkout and create. The main thrust of the checkout command is to change branches so if a branch does not exist they give you a convenience method to do so.

edit: git add -p(atch) is supposed to create patches of existing files assuming that that is the most common use case. Use --interactive if you want to add new files and still do interactive patching.

I am aware why the distinction exists - from the perspective of "git(1) manipulates the git file system", it make sense (as I wrote). But most people I know tend to use "branch" for all their branching work (as the name implies) and never bother about the finer details. But the fact that this sore point exists and is real makes the git UI problematic. I don't bother, because I know the details, but if I have to explain it to every new guy in the office, there is something wrong.

About git add -p: yes, I am aware of -i, but it doesn't give you the easy "give me all changes to the file system and let me sign them off"-interaction that git add -p has. They are two completely different interaction modes.

git add -i

5<enter>

*<enter>(all changed files) or 1-5<enter>(files 1-5 in the list) or 1,5,3<enter>(files 1, 5 and 3) etc...

then <enter> gets you to the staging that you are used to. this will get you into the quick patch mode that -p does.

-p is just a short circuit of this.

You might find `git add -N` ("--intent-to-add") useful. It's an extra step, yes, but it allows you to e.g. view the content of new files with `git diff` without actually staging the content for commit, and will allow you to stage that file during `git add -p`.

Reply on news.ycombinator.com