5 ms·

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

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.

sauravc 14y ago
I agree with the your first line. It espouses objectivity. But your second line goes in the opposite direction and make me sad.
- ktizo 14y ago
  Might be cerebral hemispheres taking turns. naarf.
josefonseca 14y ago
> 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!
- delroth 14y ago
  Bitkeeper. Bitbucket (and Mercurial) did not exist when Linus started writing Git.
  - josefonseca 14y ago
    I stand corrected.
- llimllib 14y ago
  ugh, stop the name calling. Surely you mean that bitkeeper is the reason Linus wrote git. Bitbucket didn't exist when he did.
- wglb 14y ago
  But RCS was a little better. In fact, i think that project invented the reverse diff
andos 14y ago
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?
bad_user 14y ago
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.
- viraptor 14y ago
  > 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.
  - bad_user 14y ago
    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...
deleted 14y ago
[deleted]
lobo_tuerto 14y ago
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.
smacktoward 14y ago
> 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.

sauravc 14y ago

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

ktizo 14y ago
Might be cerebral hemispheres taking turns. naarf.

josefonseca 14y ago

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

delroth 14y ago
Bitkeeper. Bitbucket (and Mercurial) did not exist when Linus started writing Git.
- josefonseca 14y ago
  I stand corrected.
llimllib 14y ago
ugh, stop the name calling. Surely you mean that bitkeeper is the reason Linus wrote git. Bitbucket didn't exist when he did.
wglb 14y ago
But RCS was a little better. In fact, i think that project invented the reverse diff

andos 14y ago

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?

bad_user 14y ago

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.

viraptor 14y ago
> 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.
- bad_user 14y ago
  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...

deleted 14y ago

[deleted]

lobo_tuerto 14y ago

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.

smacktoward 14y ago

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