7 ms·

While he'd been working with and thinking about the problem for a long time the speed at which Linus produced Git always amazes me: "development of Git began o

While he'd been working with and thinking about the problem for a long time the speed at which Linus produced Git always amazes me: "development of Git began on 3 April 2005...On 16 June, the kernel 2.6.12 release was managed by Git...Torvalds turned over maintenance on 26 July 2005".[1] Perhaps he should have some more breaks for side projects. [1]https://en.wikipedia.org/wiki/Git_(software) https://en.wikipedia.org/wiki/Git_(software)

riquito 12y ago
During his speech at Google "[after reviewing the alternatives] the end results was I decided I can write something better than anything out there in two weeks. And I was right" http://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&t=12m16s http://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&...
- read 12y ago
  Something's still not clear about his assumptions in that talk. He says "you just continue to work" and "you could do everything you would do" [if you were connected online]. But this is not true when it comes to integration of source control with issue-tracking. If you integrate source control with issue-tracking, you start to want source code changes to correspond to issue numbers, and changes to be pushed if an issue is in a certain state or owned by a specific developer. But you can't get this information when you are offline without access to the issue-tracker. Either there's a case for distributed issue-tracking too, which would give you that information, or issue-tracking being centralized pushes back on source control wanting to be distributed. I wish this was addressed in Git's assumptions.
  - modeless 12y ago
    Sounds like you want https://www.fossil-scm.org https://www.fossil-scm.org. Distributed version control with integrated wiki and bug tracking, from the creator of SQLite.
    - selectnull 12y ago
      Another option is Veracity by Sourcegear. http://veracity-scm.com/ http://veracity-scm.com/
      - hrjet 12y ago
        Their DVCS comparison page is very informative: http://veracity-scm.com/compare/ http://veracity-scm.com/compare/
  - ithkuil 12y ago
    https://github.com/schacon/ticgit/wiki https://github.com/schacon/ticgit/wiki YMMV
  - mtdewcmu 12y ago
    I've been mulling over issue tracking lately, since I hate Jira and all the other ones I've used. Wouldn't issues being in states and having owners violate the distributed model? Version control used to have file owners and locks, which is the same thing, and git broke from that.
- zenbowman 12y ago
  Yeah, that was a great talk. I highly recommend people watch it. He was definitely right about that, what I like about Linus is he really does seem to prefer to do things in as concrete and simple a way as possible instead of getting mired in abstractions.
- pags 12y ago
  Isn't he blurring the line between "commit" meaning creating a state you can roll back to (in all version control systems), and "commit" meaning pushing to the "official" code base in a non-distributed system? In other words, some issues with non-distributed systems that he highlights (having to keep an elite group deemed smart enough to integrate changes, for example) still exist when pushing to a consensus "official" instance of a distributed repo.
  - jordigh 12y ago
    His language is pretty muddled in this talk. It's clear he didn't really spend a lot of time thinking about precise and unambiguous language for all of the things he was talking about. He also seems to conflate "branch" and "clone". This muddled language later turned into a muddled UI that was supposed to get cleaned up, but never did.
    - pags 12y ago
      I can't help but think that he was conveniently leaving out details that give the entire story - clearly he thinks the audience are unintelligent sheep, so surely they'll take him at his word, right?
    - kdd44 12y ago
      In what way does git conflate "branch" and "clone"?
  - richardwhiuk 12y ago
    Probably because those two actions are identical in CVS, SVN etc, which most people at the talk were familiar with, unlike the commit and push states in a DVCS (hg, git, bzr etc).
- jordigh 12y ago
  Writing the basics of a DVCS in two weeks isn't a unique feat. Mercurial was created in almost exactly the same way, and was faster than git (and still is, e.g. for blame and clone operations) and actually was conceived with a UI from the beginning. I'm pretty sure the only reason git took most of the mind share instead of hg was (1) github (2) Linus admiration.
  - codemac 12y ago
    Well, you're also missing some reasons: - git has an 'email' centric workflow - The index with git (git add -i) awesome for people doing patch maintenance - the rebase workflow is great when you want to maintain against an upstream that you expect someone other than you to commit your changes to, or you have a "pre-publish" phase. It's almost like those reasons follow the linux workflow.. almost perfectly.
    - zurn 12y ago
      Those aren't big things outside Linux.
      - throwaway7767 12y ago
        Email centric workflows are used for lots of projects other than the linux kernel. My workflow for a lot of the projects I contribute to is something like: edit -> commit (repeat as necessary) -> rebase -i -> format-patch -> send patchset by email
    - Argorak 12y ago
      > - git has an 'email' centric workflow Which is surprising, given how rough all the email-involving commands of git are. Badly documented (git-send-email man page doesn't even come close to documenting all options properly), awful error reporting and a badly explained (although, in itself, quite sane) workflow when sending the patches. When setting up my email setup, I consulted the underlying Perl script more than the docs :(.
    - read 12y ago
- jonalmeida 12y ago
  He mentions that git wasn't half as good if it wasn't for the help he got after his initial creation that made it cleaner and better.
- reledi 12y ago
  According to his recent save format post [1], he spends a lot of time thinking about something before he starts prototyping. > So I've been thinking about this for basically months, but the way I work, I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding. So two weeks seems reasonable to me, especially if he built a prototype first. (Did he?) 1: https://plus.google.com/102150693225130002912/posts/X2XVf9Q7MfV https://plus.google.com/102150693225130002912/posts/X2XVf9Q7...
legulere 12y ago
I wonder how much thought he put into it before he started programming, especially as BitKeeper wasn't really uncontroversial earlier.
- GFK_of_xmaspast 12y ago
  Given the git interface, one wishes it had been "a little more".
  - tcheard 12y ago
    What exactly is wrong with the git interface?
    - grannyg00se 12y ago
      Parent is downvoted but this seems like a valid question to me. The interface consists of git sub commands and their flags. One could argue that there are too many flags, or even too many commands, but why not offer flexibility when you can as long as you keep sane defaults? I think that git commit, init, add, fetch, branch, checkout, merge, and push all have sane defaults and anybody can pick up very basic git usage using those commands in less than a few hours. Things get complicated when you start looking at the details, but I don't see any way around that. And the interface doesn't change. It's just a matter of learning more flags and commands.
    - oneandoneis2 12y ago
      I've asked this a time or two, and the answers I've received so far have always boiled down to: "I don't know how to use git" or "I don't know how to alias complex commands I use frequently" Maybe you'll have better luck with the responses you get :)
    - kasey_junk 12y ago
      I have tons of little problems with it that would be silly to enumerate, but they fall into 3 broad categories. 1) Terrible tab completion support. 2) Multiple command/option permutations that do nearly the same thing with small subtle differences. 3) Lack of cohesion amongst the community around best practices (especially with regards to branching/merging/rebasing).
brongondwana 12y ago
Given all the kerfuffle about init systems, I'd love him to write a good small init process.
- vezzy-fnord 12y ago
  Pretty sure finit is helping with that: http://troglobit.com/finit.html http://troglobit.com/finit.html That, and runit has been around for a while, though I don't know much about it.
- startling 12y ago
  If he were to write an alternative, it would be given undue preference over others. He probably knows this.
  - ithkuil 12y ago
    Some people would indeed prefer to have only one (benevolent) dictator.
    - gkya 12y ago
      “Benevolent” is among the least becoming adjectives to Linus' dictatorship.
      - droopyEyelids 12y ago
        I think you're confusing "benevolent" with "deferential" or "polite".
      - kdd44 12y ago
        It's sad that people get so hung up on bashing personality differences (not flaws) that they can't even see the much greater good that some people do. Politeness is just the toleration of stupidity and the acceptance of mediocrity.
        gkya 12y ago
JustSomeNobody 12y ago
Because he likely doesn't spend half his time worrying about stupid crap like ORMs and DI frameworks.

riquito 12y ago

During his speech at Google "[after reviewing the alternatives] the end results was I decided I can write something better than anything out there in two weeks. And I was right" http://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&t=12m16s http://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&...

read 12y ago
Something's still not clear about his assumptions in that talk. He says "you just continue to work" and "you could do everything you would do" [if you were connected online]. But this is not true when it comes to integration of source control with issue-tracking. If you integrate source control with issue-tracking, you start to want source code changes to correspond to issue numbers, and changes to be pushed if an issue is in a certain state or owned by a specific developer. But you can't get this information when you are offline without access to the issue-tracker. Either there's a case for distributed issue-tracking too, which would give you that information, or issue-tracking being centralized pushes back on source control wanting to be distributed. I wish this was addressed in Git's assumptions.
- modeless 12y ago
  Sounds like you want https://www.fossil-scm.org https://www.fossil-scm.org. Distributed version control with integrated wiki and bug tracking, from the creator of SQLite.
  - selectnull 12y ago
    Another option is Veracity by Sourcegear. http://veracity-scm.com/ http://veracity-scm.com/
    - hrjet 12y ago
      Their DVCS comparison page is very informative: http://veracity-scm.com/compare/ http://veracity-scm.com/compare/
- ithkuil 12y ago
  https://github.com/schacon/ticgit/wiki https://github.com/schacon/ticgit/wiki YMMV
- mtdewcmu 12y ago
  I've been mulling over issue tracking lately, since I hate Jira and all the other ones I've used. Wouldn't issues being in states and having owners violate the distributed model? Version control used to have file owners and locks, which is the same thing, and git broke from that.
zenbowman 12y ago
Yeah, that was a great talk. I highly recommend people watch it. He was definitely right about that, what I like about Linus is he really does seem to prefer to do things in as concrete and simple a way as possible instead of getting mired in abstractions.
pags 12y ago
Isn't he blurring the line between "commit" meaning creating a state you can roll back to (in all version control systems), and "commit" meaning pushing to the "official" code base in a non-distributed system? In other words, some issues with non-distributed systems that he highlights (having to keep an elite group deemed smart enough to integrate changes, for example) still exist when pushing to a consensus "official" instance of a distributed repo.
- jordigh 12y ago
  His language is pretty muddled in this talk. It's clear he didn't really spend a lot of time thinking about precise and unambiguous language for all of the things he was talking about. He also seems to conflate "branch" and "clone". This muddled language later turned into a muddled UI that was supposed to get cleaned up, but never did.
  - pags 12y ago
    I can't help but think that he was conveniently leaving out details that give the entire story - clearly he thinks the audience are unintelligent sheep, so surely they'll take him at his word, right?
  - kdd44 12y ago
    In what way does git conflate "branch" and "clone"?
- richardwhiuk 12y ago
  Probably because those two actions are identical in CVS, SVN etc, which most people at the talk were familiar with, unlike the commit and push states in a DVCS (hg, git, bzr etc).
jordigh 12y ago
Writing the basics of a DVCS in two weeks isn't a unique feat. Mercurial was created in almost exactly the same way, and was faster than git (and still is, e.g. for blame and clone operations) and actually was conceived with a UI from the beginning. I'm pretty sure the only reason git took most of the mind share instead of hg was (1) github (2) Linus admiration.
- codemac 12y ago
  Well, you're also missing some reasons: - git has an 'email' centric workflow - The index with git (git add -i) awesome for people doing patch maintenance - the rebase workflow is great when you want to maintain against an upstream that you expect someone other than you to commit your changes to, or you have a "pre-publish" phase. It's almost like those reasons follow the linux workflow.. almost perfectly.
  - zurn 12y ago
    Those aren't big things outside Linux.
    - throwaway7767 12y ago
      Email centric workflows are used for lots of projects other than the linux kernel. My workflow for a lot of the projects I contribute to is something like: edit -> commit (repeat as necessary) -> rebase -i -> format-patch -> send patchset by email
  - Argorak 12y ago
    > - git has an 'email' centric workflow Which is surprising, given how rough all the email-involving commands of git are. Badly documented (git-send-email man page doesn't even come close to documenting all options properly), awful error reporting and a badly explained (although, in itself, quite sane) workflow when sending the patches. When setting up my email setup, I consulted the underlying Perl script more than the docs :(.
  - read 12y ago
jonalmeida 12y ago
He mentions that git wasn't half as good if it wasn't for the help he got after his initial creation that made it cleaner and better.
reledi 12y ago
According to his recent save format post [1], he spends a lot of time thinking about something before he starts prototyping. > So I've been thinking about this for basically months, but the way I work, I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding. So two weeks seems reasonable to me, especially if he built a prototype first. (Did he?) 1: https://plus.google.com/102150693225130002912/posts/X2XVf9Q7MfV https://plus.google.com/102150693225130002912/posts/X2XVf9Q7...

legulere 12y ago

I wonder how much thought he put into it before he started programming, especially as BitKeeper wasn't really uncontroversial earlier.

GFK_of_xmaspast 12y ago
Given the git interface, one wishes it had been "a little more".
- tcheard 12y ago
  What exactly is wrong with the git interface?
  - grannyg00se 12y ago
    Parent is downvoted but this seems like a valid question to me. The interface consists of git sub commands and their flags. One could argue that there are too many flags, or even too many commands, but why not offer flexibility when you can as long as you keep sane defaults? I think that git commit, init, add, fetch, branch, checkout, merge, and push all have sane defaults and anybody can pick up very basic git usage using those commands in less than a few hours. Things get complicated when you start looking at the details, but I don't see any way around that. And the interface doesn't change. It's just a matter of learning more flags and commands.
  - oneandoneis2 12y ago
    I've asked this a time or two, and the answers I've received so far have always boiled down to: "I don't know how to use git" or "I don't know how to alias complex commands I use frequently" Maybe you'll have better luck with the responses you get :)
  - kasey_junk 12y ago
    I have tons of little problems with it that would be silly to enumerate, but they fall into 3 broad categories. 1) Terrible tab completion support. 2) Multiple command/option permutations that do nearly the same thing with small subtle differences. 3) Lack of cohesion amongst the community around best practices (especially with regards to branching/merging/rebasing).

brongondwana 12y ago

Given all the kerfuffle about init systems, I'd love him to write a good small init process.

vezzy-fnord 12y ago
Pretty sure finit is helping with that: http://troglobit.com/finit.html http://troglobit.com/finit.html That, and runit has been around for a while, though I don't know much about it.
startling 12y ago
If he were to write an alternative, it would be given undue preference over others. He probably knows this.
- ithkuil 12y ago
  Some people would indeed prefer to have only one (benevolent) dictator.
  - gkya 12y ago
    “Benevolent” is among the least becoming adjectives to Linus' dictatorship.
    - droopyEyelids 12y ago
      I think you're confusing "benevolent" with "deferential" or "polite".
    - kdd44 12y ago
      It's sad that people get so hung up on bashing personality differences (not flaws) that they can't even see the much greater good that some people do. Politeness is just the toleration of stupidity and the acceptance of mediocrity.
      - gkya 12y ago

JustSomeNobody 12y ago

Because he likely doesn't spend half his time worrying about stupid crap like ORMs and DI frameworks.