Hacker News Reader

Comment by lobo_tuerto | Hacker News Reader

I hope the github folks get involved in this. I'm specially interested in what they have to say about why they decided to go with what Linus calls _their own totally inferior version_.

Love this no-nonsense style, but let me say that it's no only the style, but that Linus has enough on his side to back it up.

View on HN

He made the same comments when he first moved some projects to GitHub. I believe the kernel.org servers were having issues at the time. In response to these comments, we pushed out several changes nearly immediately, including a completely redesigned Pull Request email notification.

We're always listening for feedback and are working on improving the experience for everyone. It's too bad that useful bits of feedback like this turn into another drama episode though.

Unrelated note: why is there not a news feed for each project? I have a news feed with tons of watched repositories but they all blend together in an unusable mess. I would like to see the history of a project that is not just commits. something like /<user>/<project>/timeline that shows all activity (commits, comments, pull requests, issues, etc....)

You only love the style because he has enough on his side to back it up. Anyone else that acted like Linus does on a regular basis would be considered childish and arrogant.

I'd take Github's version of any feature, any day, over the official git version, any time they differed - Git is a notoriously user-hostile piece of software interface-wise, and pretty much the only thing it has going for it on the usability front is Github.

I agree with the your first line. It espouses objectivity. But your second line goes in the opposite direction and make me sad.

Might be cerebral hemispheres taking turns. naarf.

> Git is a notoriously user-hostile piece of software

Then you probably didn't use any SCCS before git. Because CVS is even uglier, Bitkeeper is the reason Linus wrote git and every other I tried was more "user-hostile" than git.

> pretty much the only thing it has going for it on the usability front is Github.

You sound like a Visual Basic programmer who just saw C for the first time.

Edit: Bitkeeper, not bucket!

Bitkeeper. Bitbucket (and Mercurial) did not exist when Linus started writing Git.

I stand corrected.

ugh, stop the name calling.

Surely you mean that bitkeeper is the reason Linus wrote git. Bitbucket didn't exist when he did.

But RCS was a little better. In fact, i think that project invented the reverse diff

So, you are saying that if you were the maintainer of a project which required a feature such that the Github implementation was inadequate but the official git implementation was OK, you'd use the Github implementation anyway?

     Git is a notoriously user-hostile piece
     of software interface-wise

It's funny you say that, because Git is the only version control system where working with branches, forks and merges in big projects is not only doable, but in 90% of the cases painless. You can't really appreciate Git until you've tried doing the same tasks in Perforce, SVN and CVS. No other similar software has the same painless approach to branching and merging, not even other distributed systems.

Also, its interface is hostile because it requires the user to understand a little about its internals. You may disagree that this is good design, however it gives you unprecedented control over the repository, which you need often when the shit hits the fan. Also, Git is freakishly fast and efficient. Much like C, an interface done with taste, but that doesn't appeal to those with weak hearts. And the fact that such projects as Linux are maintained with Git, projects which have a huge number of contributers, it's a true testament to Git's awesomeness.

And btw, considering how version control is one of the most important tools at your disposal, if not the most important in big teams, stop reading those SVN 2 Git tutorials and go read a freaking manual. It's worth it, because you'd be amazed at how much power it has under the hood.

> Also, Git is freakishly fast and efficient. Much like C, an interface done with taste

I don't agree with the second claim and the first one does not explain it being that way. What is so tasteful about this:

    # delete
    git remote rm ...
    git branch -D ...
    git tag -d ...
    git rm ...

    # rename
    git remote rename old new
    git branch -m old new
    # can't git tag ...
    git mv

No - it may be useful, it may be fast, it may be efficient. But the interface sucks completely and is very inconsistent both between the commands and in what is each command's responsibility.

First of all, all of these commands make perfect sense to me. I don't know why exactly, but I've never used a version control system that made more sense than this. I never really felt like I'm home with Perforce and SVN. Neither with Mercurial, although Mercurial is better than most.

    git remote rm

This deletes the reference to a remote repository. The difference between Git and SVN here is that in Git you can have multiple remote repositories with which you can communicate.

This comes in handy when pulling and pushing to/from multiple people. Imagine swapping code between you and your colleagues, doing experiments, doing code reviews, and so on. It also comes in handy when you're dealing with Heroku, or when you've got an "open-source" core that's pushed to GitHub and another branch with proprietary additions that you push somewhere else.

Also, all commands for managing these repository references start with "git remote" and to find out how to do something with them you just do "man git-remote".

    git branch -D

This deletes a local branch. It has nothing to do with the above. It does not use "rm" because that can be the name of a branch and this command is heavily overloaded.

    git tag -d

This deletes a tag. It is consistent with the above command, as "git branch -d" (lowercase D) is also supported, but uppercase D means that the deletion is forced, even if the branch was not merged. Again "rm" was not used, as that can be confused with the name of a tag.

    git rm

Deletes a file, but you don't have to use it. If you're confident about your editing skills, you can just commit all the deletions with "git commit -a ..." ... git will also be smart enough to detect a file rename, even though you did a deletion + addition.

"rm" is also the name of the command that does the same thing in Unix, being associated with the removal of files.

     git remote rename old new

As I said, "git remote" manages references to remote repositories. This just renames the reference named "old" to "new".

You could say that they should have used "mv", like in the case of "git mv", however this is not a "move" command. This is just plain renaming.

     git branch -m old new

This renames the local branch named "old" to "new". It is indeed inconsistent with the others, but that's because the "git branch" utility has been overloaded a lot. This command does confuse me from time to time.

     git mv

Like in the case of "git rm", this command does a "mv", while registering the action in Git. It is also not necessary if you're doing a "git add . && git commit -a".

"mv" does make sense here, as it is the name of the Unix command for moving files.

And a final tip for beginners: use the "man" pages. In a terminal input any of the following commands when you need help ...

    man git-remote
    man git-branch
    man git-tag
    man git-rm
    man git-mv
    man git-push
    man git-pull
    man git-reset
    man git-checkout
    etc...

Sure they make sense if you have it in front of you and want to know what they do. They stop making sense when you want to write them - why do you have to have different way to deal with each type of an object. Either stick to -d/-D convention, or rm/rm --force, or delete/delete --force, or something else... just don't mix up calling conventions just because you operate on a different kind of object. Same goes for listing things, renaming, etc.

My point was about inconsistencies rather than not being able to figure out which command did what.

IIRC, Facebook ran into performance issues with git.

https://news.ycombinator.com/item?id=3548824

Not sure if they have been resolved.

Google style mono-repository development currently appears to be impossible with Git. If there was a more robust way to manage multiple repositories as a single one, that might work -- subtree and submodule aren't cutting it.

I value no-nonsense style in itself. It's efficient and direct to the point. If you don't have something to back it up, then it is no no-nonsense whatsoever. It'd be just plain nonsense.

> You only love the style because he has enough on his side to back it up. Anyone else that acted like Linus does on a regular basis would be considered childish and arrogant.

Probably true, but when you've changed the technology world twice before age 40 people tend to cut you some additional slack.

It's the enfant terrible style. Signals that you are special, and are willing to back it up, so let's just end the conversation. Nice time saver when you actually are special and can back it up. Terrifically destructive for a "B" surrounded by timid people. A good way to drive a team right over the cliff. I've seen a lot of the latter so I tend to react negatively to it. Plus it's never really "nice".

How is GitHubs "version" inferior? The technology that Linus uses to do pull requests (email) validates even less than a GitHub pull request does. The Linux kernel and git have standards that enforce that e-mail pull requests have to follow certain guidelines, but it's not impossible to apply these guidelines to GitHub.

Reply on news.ycombinator.com