7 ms·

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.

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