8 ms·

"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any

"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible software with an even worse UX that just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess?

rootlocus 10y ago
> just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess? I would assume GitHub is to blame for that
wkd 10y ago
I'm struggling to see which VCS you deem superior, I'm assuming you are not referring to SVN, Mercurial maybe? The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in the way or try to find a better workflow.
- pjc50 10y ago
  SVN is much easier to use for the standard corporate workflow of a group of people making commits to a project which mostly advances monotonically with continuous integration. Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere. It also took a while to work out how to kill (with fast-forward) the spurious "merge commit" you get every time someone does a pull. You don't have that with svn, you just do the merging locally when you update and it doesn't generate a commit.
  - tempodox 10y ago
    I concur. I would assume that git is the right tool for Linus's workflow, but whatever that is, it isn't mine. SVN does all I need and it has a friendly API and helpful documentation. In other words, the exact opposite of git.
  - deleted 10y ago
    [deleted]
  - brusch64 10y ago
    I've been using Subversion since 10 years or so and I've changed completely to Git, so I've got experience with it. For me Git was really a much needed upgrade to subversion. Working with branches (testing and production, we even have some repositories with multiple testing and production branches) are working like they are supposed to do. Changing commits (oops - I forgot to add one file) before pushing them to the repository for the other users is another big advantage. Working on multiple features in parallel - I couldn't do that with Subversion. We've nearly completely eliminated the "handcrafted" local copies with multiple half finished features since changing to Git. And if you want to use Git as a Subversion alternative you can use it in this mode too - altough you are missing out on some good new features. I don't want to change back to Subversion. The only disadvantage is that SourceTree (the GUI tool we are using) is a pretty lame duck in Windows. But the command line is excellent.
    - TickleSteve 10y ago
      So what problems exactly did you have with SVN? branches are branches in svn or git... your process may not have been correct, but lets not blame the tools here.. modifying commits is a big no-no for me, so thats not a drawback at all, the fact that its not possible in svn is a win for svn.
      - brusch64 10y ago
        I really like modifying commits (as long as they are not pushed) - but I know that this is quite a controversial topic. For one of our biggest projects branches in SVN didn't work at all. We have multiple production, test and development branches and merge branches (features) from one branch to the other (development -> testing -> production). Sometimes we cherry pick a single commit to another branch. In those days SVN wasn't so flexibel with branches as we wanted to (or we didn't understand it enough), so our workflow was much more rigid.
- ewjordan 10y ago
  Yep, Mercurial's the one. It's a shame that it lost the war, they actually seemed to care about providing a good experience to their users. There are, of course, a few technical differences between it and git, but I personally never felt like they were troublesome enough to make up for the vast difference in usability.
  - marcinkuzminski 10y ago
    I think Mercurial hasn't lost it yet. I speak as a creator of Mercurial Source Code management system (RhodeCode) We see that a lot of companies(our clients/users) adopting Mercurial, you just don't hear about it. Often those are companies with employees that don't tweet or post to HN ;) RhodeCode is used also in around 60 universities, and we learned that in a lot of them they teach Mercurial as well as Git. For a large company it's actually much cheaper to adapt Mercurial as they new DVCS because of learning curve. I hope companies like Facebook and Mozilla will make soon Mercurial very very fast. There's constant work on it coming from those companies to improve it.
    - RJIb8RBYxzAMX9u 10y ago
      I don't think hg is going anywhere, if CVS is still alive and kicking in 2016, and especially since Facebook's using it. However, IMO hg lost when even python switched to git.
brusch64 10y ago
What are the superior foes in your opinion ? I don't know any of the other distributed version control systems. The only other version control system I have much (too much) experience with is Subversion and it can't hold a candle against Git. In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. Otherwise you have a really great tool with lots of power.
- TickleSteve 10y ago
  Can you justify git>subversion or are you just following the sheep? Not saying I disagree... but subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. Just beware of having unjustified-opinions. SVN may not be trendy... but neither will git in a few years time. BTW: Mercurial still beats them all.
  - Grue3 10y ago
    >subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. For some values of "work". We're using SVN at my new job, with a single trunk branch. Not having the ability to commit locally, and mess around with local branches is a pain in the ass. I found a solution though. I cloned SVN repo using git-svn and now I can make local commits like a pro, and use my beloved magit (Emacs git interface).
    - apk17 10y ago
      Yes, git-svn is probably the reason why the mutiny didn't happen yet in some departments. You can identify their users by having several SVN commits in as many seconds. (I used git in an cvs-to-svn migration, and stayed since.)
  - brusch64 10y ago
    for me the biggest advantage is working in my own repository and then pushing the changes upstream. I can develop features independent of other features. If there is a bug I can fix it, merge it into the productive branch and carry on working on other features. I know that many people don't like it, but I can fix up commits in my local repository and push the change upstream in one. With SVN I wasn't able to do this, so it was a big pain if you had to fix a bug if you were in the middle of a big feature, or if you had an experimental feature you wanted to clean up and release a month later.
Singletoned 10y ago
> Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. You forgot "brilliant".
- TickleSteve 10y ago
  not necessarily better than most other good engineers... He knows a lot about his domain, sure, but he's no god and there are a lot of areas he knows diddley-squat about.... user interface design for one!
  - Singletoned 10y ago
    > He knows a lot about his domain, sure, but he's no god and there are a lot of areas he knows diddley-squat about.... user interface design for one! And Einstein knew nothing about biology. I'm sure he knows "diddley-squat" about most areas, but as long as he knows a lot about his domain then he's an expert. And he is good at user interface design, and git is a good example of that; it's just not aimed at beginners. It was designed by and for expert users, and the interface fits that very well.
    - TickleSteve 10y ago
      no, its not a good UI. admittedly "expert" UIs are different from "noob" UIs, but the number of "git magic spell" followers out there mean that it isn't a good UI for the majority of people who use git.
      - dozzie 10y ago
        Well, if you treat git as Torvalds intended it in the beginning (framework for building VCS-es) and accordingly limit the discussion to git's plumbing command set, you get a sensibly good UI+architecture that is targeted at programmers that write VCS-es. Git being operable with a pry bar and repairable with a hammer is a good proof that in this context it's a good design.
  - 10y ago
tempodox 10y ago
> ... that just happened to win the PR battle ... Chalk that up to the power of fashion. Otherwise, people would use an SCM that doesn't destroy their work in the blink of an eye and actually has an API that deserves the name.
- EdiX 10y ago
  The only way to lose work with git is either to (a) not commit it or (b) run a garbage collection.
  - apk17 10y ago
    ...and having commits that are not referenced by any branch. And (c) lose the entire subtree the repo is in.
    - deleted 10y ago
      [deleted]
dboreham 10y ago
First time I've wanted to upvote twice! I think besides a PR battle (there's PR people for RCS'es??) I think Git won out because "the server was free". Competitors at the time needed a big (if there were large numbers of committers) server that someone had to pay for. By that I mean the hardware to host the server -- Git needs either none, or a very lightweight machine for a server.
infodroid 10y ago
> terrible software The Git DAG and its content-addressable file system are an elegant solution to the problem of distributed version control. The implementation is clean and dead-simple, yet immensely powerful. This is the basis of good engineering. > an even worse UX Git was designed to expose its underlying implementation and not to isolate the user from it. Unlike other systems, its subcommands give the user the ability to manipulate the underlying data structure directly. That doesn't mean it has a bad UX. Just that it has the UX of a power tool. I also think that Git played a big role in the growth and popularity of command-line tools over the past decade. And that its interface inspired the subcommand pattern that is now commonplace in docker, vagrant, and others.

rootlocus 10y ago

> just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess? I would assume GitHub is to blame for that

wkd 10y ago

I'm struggling to see which VCS you deem superior, I'm assuming you are not referring to SVN, Mercurial maybe? The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in the way or try to find a better workflow.

pjc50 10y ago
SVN is much easier to use for the standard corporate workflow of a group of people making commits to a project which mostly advances monotonically with continuous integration. Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere. It also took a while to work out how to kill (with fast-forward) the spurious "merge commit" you get every time someone does a pull. You don't have that with svn, you just do the merging locally when you update and it doesn't generate a commit.
- tempodox 10y ago
  I concur. I would assume that git is the right tool for Linus's workflow, but whatever that is, it isn't mine. SVN does all I need and it has a friendly API and helpful documentation. In other words, the exact opposite of git.
- deleted 10y ago
  [deleted]
- brusch64 10y ago
  I've been using Subversion since 10 years or so and I've changed completely to Git, so I've got experience with it. For me Git was really a much needed upgrade to subversion. Working with branches (testing and production, we even have some repositories with multiple testing and production branches) are working like they are supposed to do. Changing commits (oops - I forgot to add one file) before pushing them to the repository for the other users is another big advantage. Working on multiple features in parallel - I couldn't do that with Subversion. We've nearly completely eliminated the "handcrafted" local copies with multiple half finished features since changing to Git. And if you want to use Git as a Subversion alternative you can use it in this mode too - altough you are missing out on some good new features. I don't want to change back to Subversion. The only disadvantage is that SourceTree (the GUI tool we are using) is a pretty lame duck in Windows. But the command line is excellent.
  - TickleSteve 10y ago
    So what problems exactly did you have with SVN? branches are branches in svn or git... your process may not have been correct, but lets not blame the tools here.. modifying commits is a big no-no for me, so thats not a drawback at all, the fact that its not possible in svn is a win for svn.
    - brusch64 10y ago
      I really like modifying commits (as long as they are not pushed) - but I know that this is quite a controversial topic. For one of our biggest projects branches in SVN didn't work at all. We have multiple production, test and development branches and merge branches (features) from one branch to the other (development -> testing -> production). Sometimes we cherry pick a single commit to another branch. In those days SVN wasn't so flexibel with branches as we wanted to (or we didn't understand it enough), so our workflow was much more rigid.
ewjordan 10y ago
Yep, Mercurial's the one. It's a shame that it lost the war, they actually seemed to care about providing a good experience to their users. There are, of course, a few technical differences between it and git, but I personally never felt like they were troublesome enough to make up for the vast difference in usability.
- marcinkuzminski 10y ago
  I think Mercurial hasn't lost it yet. I speak as a creator of Mercurial Source Code management system (RhodeCode) We see that a lot of companies(our clients/users) adopting Mercurial, you just don't hear about it. Often those are companies with employees that don't tweet or post to HN ;) RhodeCode is used also in around 60 universities, and we learned that in a lot of them they teach Mercurial as well as Git. For a large company it's actually much cheaper to adapt Mercurial as they new DVCS because of learning curve. I hope companies like Facebook and Mozilla will make soon Mercurial very very fast. There's constant work on it coming from those companies to improve it.
  - RJIb8RBYxzAMX9u 10y ago
    I don't think hg is going anywhere, if CVS is still alive and kicking in 2016, and especially since Facebook's using it. However, IMO hg lost when even python switched to git.

brusch64 10y ago

What are the superior foes in your opinion ? I don't know any of the other distributed version control systems. The only other version control system I have much (too much) experience with is Subversion and it can't hold a candle against Git. In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. Otherwise you have a really great tool with lots of power.

TickleSteve 10y ago
Can you justify git>subversion or are you just following the sheep? Not saying I disagree... but subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. Just beware of having unjustified-opinions. SVN may not be trendy... but neither will git in a few years time. BTW: Mercurial still beats them all.
- Grue3 10y ago
  >subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. For some values of "work". We're using SVN at my new job, with a single trunk branch. Not having the ability to commit locally, and mess around with local branches is a pain in the ass. I found a solution though. I cloned SVN repo using git-svn and now I can make local commits like a pro, and use my beloved magit (Emacs git interface).
  - apk17 10y ago
    Yes, git-svn is probably the reason why the mutiny didn't happen yet in some departments. You can identify their users by having several SVN commits in as many seconds. (I used git in an cvs-to-svn migration, and stayed since.)
- brusch64 10y ago
  for me the biggest advantage is working in my own repository and then pushing the changes upstream. I can develop features independent of other features. If there is a bug I can fix it, merge it into the productive branch and carry on working on other features. I know that many people don't like it, but I can fix up commits in my local repository and push the change upstream in one. With SVN I wasn't able to do this, so it was a big pain if you had to fix a bug if you were in the middle of a big feature, or if you had an experimental feature you wanted to clean up and release a month later.

Singletoned 10y ago

> Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. You forgot "brilliant".

TickleSteve 10y ago
not necessarily better than most other good engineers... He knows a lot about his domain, sure, but he's no god and there are a lot of areas he knows diddley-squat about.... user interface design for one!
- Singletoned 10y ago
  > He knows a lot about his domain, sure, but he's no god and there are a lot of areas he knows diddley-squat about.... user interface design for one! And Einstein knew nothing about biology. I'm sure he knows "diddley-squat" about most areas, but as long as he knows a lot about his domain then he's an expert. And he is good at user interface design, and git is a good example of that; it's just not aimed at beginners. It was designed by and for expert users, and the interface fits that very well.
  - TickleSteve 10y ago
    no, its not a good UI. admittedly "expert" UIs are different from "noob" UIs, but the number of "git magic spell" followers out there mean that it isn't a good UI for the majority of people who use git.
    - dozzie 10y ago
      Well, if you treat git as Torvalds intended it in the beginning (framework for building VCS-es) and accordingly limit the discussion to git's plumbing command set, you get a sensibly good UI+architecture that is targeted at programmers that write VCS-es. Git being operable with a pry bar and repairable with a hammer is a good proof that in this context it's a good design.
- 10y ago

tempodox 10y ago

> ... that just happened to win the PR battle ... Chalk that up to the power of fashion. Otherwise, people would use an SCM that doesn't destroy their work in the blink of an eye and actually has an API that deserves the name.

EdiX 10y ago
The only way to lose work with git is either to (a) not commit it or (b) run a garbage collection.
- apk17 10y ago
  ...and having commits that are not referenced by any branch. And (c) lose the entire subtree the repo is in.
  - deleted 10y ago
    [deleted]

dboreham 10y ago

First time I've wanted to upvote twice! I think besides a PR battle (there's PR people for RCS'es??) I think Git won out because "the server was free". Competitors at the time needed a big (if there were large numbers of committers) server that someone had to pay for. By that I mean the hardware to host the server -- Git needs either none, or a very lightweight machine for a server.

infodroid 10y ago

> terrible software The Git DAG and its content-addressable file system are an elegant solution to the problem of distributed version control. The implementation is clean and dead-simple, yet immensely powerful. This is the basis of good engineering. > an even worse UX Git was designed to expose its underlying implementation and not to isolate the user from it. Unlike other systems, its subcommands give the user the ability to manipulate the underlying data structure directly. That doesn't mean it has a bad UX. Just that it has the UX of a power tool. I also think that Git played a big role in the growth and popularity of command-line tools over the past decade. And that its interface inspired the subcommand pattern that is now commonplace in docker, vagrant, and others.