3 ms·

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 mu

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.
ubernostrum 10y ago
I don't know any of the other distributed version control systems. In an ideal world -- one where network effects of GitHub hadn't crushed all competition -- I'd get to choose Mercurial as my daily version-control system. It has similarities to git, in that both are largely user interfaces to a DAG, but its guiding philosophy and approach to the interface it exposes are far better in my opinion. In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. You probably don't want to make that assertion; we now have close to half a century of evidence that no human currently living can use C safely, and I don't think you'd want that to carry over to git. And it's not a matter of "careless" or not -- extremely intelligent, extremely-well-trained, extremely-careful people still write unsafe C.
- brusch64 10y ago
  >we now have close to half a century of evidence that no human currently living can use C safely How many operating systems are written in C ? How many of the more mainstream operating systems are written in other languages ? You're right that C is the wrong tool for a lot of applications. But if you need total control and speed and power it still works for many projects.
pluma 10y ago
I've heard a lot of people who seem to know their stuff say that Mercurial is superior to Git in almost every way, especially when it comes to integrating with other tooling (i.e. Mercurial seems to have an API whereas automating Git boils down to spawning shell commands). This also seems to be why Facebook switched from Git to Mercurial: they needed to be able to check out individual folders from a branch and Git simply didn't provide any way to do that without first checking out the entire branch. Be that as it may, it's a common misconception that the more popular tool is always the better tool. There are a lot of factors to a tool's success and the technical ones are generally far less important than most people think.
- majewsky 10y ago
  What's so bad about spawning shell commands?
ewjordan 10y ago
People have already mentioned it, but since I made the original comment, I'll pile on and say that Mercurial was (well, still is, but it's out of fashion now) awesome. It matches Git on most axes and blows it out of the water when it comes to usability and "don't shoot yourself in the foot"-ishness. Brushing aside some relatively minor differences, Mercurial is very similar to Git, except that it was designed by people that don't have an all-consuming disdain for all of humankind.

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.

ubernostrum 10y ago

I don't know any of the other distributed version control systems. In an ideal world -- one where network effects of GitHub hadn't crushed all competition -- I'd get to choose Mercurial as my daily version-control system. It has similarities to git, in that both are largely user interfaces to a DAG, but its guiding philosophy and approach to the interface it exposes are far better in my opinion. In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. You probably don't want to make that assertion; we now have close to half a century of evidence that no human currently living can use C safely, and I don't think you'd want that to carry over to git. And it's not a matter of "careless" or not -- extremely intelligent, extremely-well-trained, extremely-careful people still write unsafe C.

brusch64 10y ago
>we now have close to half a century of evidence that no human currently living can use C safely How many operating systems are written in C ? How many of the more mainstream operating systems are written in other languages ? You're right that C is the wrong tool for a lot of applications. But if you need total control and speed and power it still works for many projects.

pluma 10y ago

I've heard a lot of people who seem to know their stuff say that Mercurial is superior to Git in almost every way, especially when it comes to integrating with other tooling (i.e. Mercurial seems to have an API whereas automating Git boils down to spawning shell commands). This also seems to be why Facebook switched from Git to Mercurial: they needed to be able to check out individual folders from a branch and Git simply didn't provide any way to do that without first checking out the entire branch. Be that as it may, it's a common misconception that the more popular tool is always the better tool. There are a lot of factors to a tool's success and the technical ones are generally far less important than most people think.

majewsky 10y ago
What's so bad about spawning shell commands?

ewjordan 10y ago

People have already mentioned it, but since I made the original comment, I'll pile on and say that Mercurial was (well, still is, but it's out of fashion now) awesome. It matches Git on most axes and blows it out of the water when it comes to usability and "don't shoot yourself in the foot"-ishness. Brushing aside some relatively minor differences, Mercurial is very similar to Git, except that it was designed by people that don't have an all-consuming disdain for all of humankind.