7 ms·

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java?

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

falcolas 13y ago
As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.
- wirrbel 13y ago
  The success of git is - apart from the speed - related with its property of being the "stupid content tracker". Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly become quite complicated and in the end it is hard for the user to get a deeper understanding of the system. The funny aspect of this is, that a lot of people complain about Gits bad user interface. It turns out however that Git is really easy to grasp.
  - dasil003 13y ago
    Exactly. The git data model is intuitive and easy to grasp after a short amount of time. The porcelain is poorly designed, but part of that is due to the flexibility of primitives underneath, and the desire to support arbitrary workflows. Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn makes it impossible for it ever achieve 20% of git's functionality simply because things are so poorly defined. After using git for 6 months I understood it better than I did about svn in the previous 5 years. I would prefer a better porcelain, but given that software development is my full time job and that I can use git for all software development regardless of the language, I'm happy to commit a bit of muscle memory to git's idiosyncrasies.
    - chx 13y ago
      > the desire to support arbitrary workflows. Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch. git , I believe , is the textbook case of what the opposite of a user friendly UI is. commands have switches which change the command so fundamentally it should be another command. Which noone wants 'cos there are like 140 commands already. switches which across commands do the same thing but are named differently. The same command doing wildly disparate things without any indication of what's happening -- try git checkout file, and guess what the state of file will be. It might from the staging area or it might come HEAD if it wasn't staged. Nuts.
      - Crito 13y ago
        > "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.
        lmm 13y ago
        I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine, the remote-tracking copies of those three on my machine, and the same again on his machine. All of which could be different. How do I reduce that complexity? I always pull and never fetch, which helps slightly, but only slightly; pull seems to fetch other branches, so it's still possible to have my copy of a branch end up behind my remote-tracking copy of that branch. There's no command analogous to pull for "add and commit and push", so that's always a second step to possibly forget (I don't want to rely on an alias as I work on a number of different machines). Most problematic at the moment is that there's no way to tell the difference between an up-to-date branch and a non-remote-tracking branch, so I sometimes delete branches that I haven't fully pushed, because I forgot to make them remote-tracking, so they didn't show up as behind when I "git status"ed.
  - StavrosK 13y ago
    > It turns out however that Git is really easy to grasp. Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.
    - Crito 13y ago
      Since you have already read ten things about it and don't understand it, it would help if you told us what you do not understand so that we do not waste our time rehashing things that you have already not understood.
      - StavrosK 13y ago
        That's a very good question. I hadn't really tried to pinpoint what exactly I don't understand about it until now, but here's what some thinking uncovered: Branching/merging/committing is pretty straightforward. The problem is that some commands seem to be very convoluted. For example, why does reset do four different things depending on whether it's soft or hard or plain? I keep having to Google to find how I can revert my latest commit. Another thing I have trouble with is obscure failures. Obviously this isn't something I can just learn, but there are times when git fails for a reason I don't understand...
        Crito 13y ago
        Ah yeah. The "why" with a lot of the porcelain stuff probably tends to be an unsatisfying "Because somebody didn't think it through very much a few years ago." git-reset would probably be better if it defaulted to --soft, and possibly left the other options to other commands.
    - reinhardt 13y ago
      Same here, whenever I attempt to give it another chance, sooner or later I break down and revert to hg-git. I recently discovered EasyGit [1] and it seems promising from the docs. There's also gitless [2] that was covered in HN a few days ago. [1] https://people.gnome.org/~newren/eg/ https://people.gnome.org/~newren/eg/ [2] http://people.csail.mit.edu/sperezde/gitless/ http://people.csail.mit.edu/sperezde/gitless/
  - gonzo 13y ago
    And we all know what runs through porcelain before it runs through plumbing.
- r0muald 13y ago
  1. Linux 2. GitHub That's it really.
lmm 13y ago
Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in the foot with pricing on their new generation (which generation was a pretty radical shift). There's not much chance of git doing that. Java did win the war; its competitors from the time are largely dying (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). You could argue that Ruby has overtaken it, but again the changes over the last ten years of ruby - and the influence of rails - have been enormous. I don't think we should stop trying to make a better VCS. But I do think we should accept that Git has won against bzr and hg in their current form; neither of those will displace git without radical changes that they are probably unsuited to make. Most likely the successor to git will be a new program entirely.
- belluchan 13y ago
  > Vim did win the war; there's still nothing better I'll just put this here for you: https://code.google.com/p/vim/source/browse/src/eval.c https://code.google.com/p/vim/source/browse/src/eval.c Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means. I've switched to emacs with evil, which in my opinion is better than vim in a lot of ways. > (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here. This isn't an argument, it's a prediction, and a stupid one. Nobody will come back to check your comment in 5 or 10 years and call you out on it. This is just the certain kind of asshat thing you can say and not worry about it coming true or not because you're some anonymous commenter making the internet richer with your irresponsible use of a keyboard.
  - 13y ago

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

falcolas 13y ago

As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.

wirrbel 13y ago
The success of git is - apart from the speed - related with its property of being the "stupid content tracker". Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly become quite complicated and in the end it is hard for the user to get a deeper understanding of the system. The funny aspect of this is, that a lot of people complain about Gits bad user interface. It turns out however that Git is really easy to grasp.
- dasil003 13y ago
  Exactly. The git data model is intuitive and easy to grasp after a short amount of time. The porcelain is poorly designed, but part of that is due to the flexibility of primitives underneath, and the desire to support arbitrary workflows. Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn makes it impossible for it ever achieve 20% of git's functionality simply because things are so poorly defined. After using git for 6 months I understood it better than I did about svn in the previous 5 years. I would prefer a better porcelain, but given that software development is my full time job and that I can use git for all software development regardless of the language, I'm happy to commit a bit of muscle memory to git's idiosyncrasies.
  - chx 13y ago
    > the desire to support arbitrary workflows. Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch. git , I believe , is the textbook case of what the opposite of a user friendly UI is. commands have switches which change the command so fundamentally it should be another command. Which noone wants 'cos there are like 140 commands already. switches which across commands do the same thing but are named differently. The same command doing wildly disparate things without any indication of what's happening -- try git checkout file, and guess what the state of file will be. It might from the staging area or it might come HEAD if it wasn't staged. Nuts.
    - Crito 13y ago
      > "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.
      - lmm 13y ago
        I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine, the remote-tracking copies of those three on my machine, and the same again on his machine. All of which could be different. How do I reduce that complexity? I always pull and never fetch, which helps slightly, but only slightly; pull seems to fetch other branches, so it's still possible to have my copy of a branch end up behind my remote-tracking copy of that branch. There's no command analogous to pull for "add and commit and push", so that's always a second step to possibly forget (I don't want to rely on an alias as I work on a number of different machines). Most problematic at the moment is that there's no way to tell the difference between an up-to-date branch and a non-remote-tracking branch, so I sometimes delete branches that I haven't fully pushed, because I forgot to make them remote-tracking, so they didn't show up as behind when I "git status"ed.
- StavrosK 13y ago
  > It turns out however that Git is really easy to grasp. Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.
  - Crito 13y ago
    Since you have already read ten things about it and don't understand it, it would help if you told us what you do not understand so that we do not waste our time rehashing things that you have already not understood.
    - StavrosK 13y ago
      That's a very good question. I hadn't really tried to pinpoint what exactly I don't understand about it until now, but here's what some thinking uncovered: Branching/merging/committing is pretty straightforward. The problem is that some commands seem to be very convoluted. For example, why does reset do four different things depending on whether it's soft or hard or plain? I keep having to Google to find how I can revert my latest commit. Another thing I have trouble with is obscure failures. Obviously this isn't something I can just learn, but there are times when git fails for a reason I don't understand...
      - Crito 13y ago
        Ah yeah. The "why" with a lot of the porcelain stuff probably tends to be an unsatisfying "Because somebody didn't think it through very much a few years ago." git-reset would probably be better if it defaulted to --soft, and possibly left the other options to other commands.
  - reinhardt 13y ago
    Same here, whenever I attempt to give it another chance, sooner or later I break down and revert to hg-git. I recently discovered EasyGit [1] and it seems promising from the docs. There's also gitless [2] that was covered in HN a few days ago. [1] https://people.gnome.org/~newren/eg/ https://people.gnome.org/~newren/eg/ [2] http://people.csail.mit.edu/sperezde/gitless/ http://people.csail.mit.edu/sperezde/gitless/
- gonzo 13y ago
  And we all know what runs through porcelain before it runs through plumbing.
r0muald 13y ago
1. Linux 2. GitHub That's it really.

lmm 13y ago

Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in the foot with pricing on their new generation (which generation was a pretty radical shift). There's not much chance of git doing that. Java did win the war; its competitors from the time are largely dying (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). You could argue that Ruby has overtaken it, but again the changes over the last ten years of ruby - and the influence of rails - have been enormous. I don't think we should stop trying to make a better VCS. But I do think we should accept that Git has won against bzr and hg in their current form; neither of those will displace git without radical changes that they are probably unsuited to make. Most likely the successor to git will be a new program entirely.

belluchan 13y ago
> Vim did win the war; there's still nothing better I'll just put this here for you: https://code.google.com/p/vim/source/browse/src/eval.c https://code.google.com/p/vim/source/browse/src/eval.c Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means. I've switched to emacs with evil, which in my opinion is better than vim in a lot of ways. > (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here. This isn't an argument, it's a prediction, and a stupid one. Nobody will come back to check your comment in 5 or 10 years and call you out on it. This is just the certain kind of asshat thing you can say and not worry about it coming true or not because you're some anonymous commenter making the internet richer with your irresponsible use of a keyboard.
- 13y ago