8 ms·

The fighting's been fun and all, but it's time to shut up and get along

90 points by tghw 17y ago

asnyder 17y ago
Poor Darcs, it's not even considered. I remember how awesome I thought Darcs was, but now we're almost done switching to Git. I would've stayed, but Git lapped Darcs on tools, performance, and stability. A shame.
- pierrefar 17y ago
  Why is it a shame that there is a much better product that meets your needs?
  - amock 17y ago
    I think it's a shame because Darcs has beautiful theory behind it and is written in my favorite programming language. I feel the same way about some hardware, like the SGI Octane with MIPS processors, dual board graphics cards, and a crossbar architecture. Practically speaking it's worthless because it pulls way too much power and even a cheap netbook is 10 times as fast, but it's still my favorite computer. So it's not a shame that there's a better product, it's a shame that the product I want to be the best isn't.
- mbrubeck 17y ago
  The author of Darcs is writing a git porcelain that uses the Darcs command-line interface and patch semantics: http://github.com/droundy/iolaus http://github.com/droundy/iolaus
  - asnyder 17y ago
    There's also darcs-git, which is a python script that allows you to run darcs command in git. http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-tools.git;a=blob;f=darcs-git.py;hb=HEAD http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-tools.g...
raganwald 17y ago
Odd, but as I was reading this I kept thinking of programming language flame wars: > So why is there so much hating? I think what’s going on is that people are coming to these languages from Java or PHP, have their massive epiphany on how totally awesome these languages are, and then assume that only their language can have this level of awesome, so they begin evangelizing. The problem, of course, is that the other guy feels the same way, and is also evangelizing, so the Ruby and the Python guy end up in a locker-room-style temper-tantrum over whose language has the best frameworks or whatnot, instead of how much more awesome their languages are than the competition. > This has to stop. > Python’s enemy is not Ruby. Ruby’s enemy is not Python. > Their enemy is Java.
d0mine 17y ago
Summary: Mercurial’s enemy is not Git. Git’s enemy is not Mercurial. Their enemy is Subversion. .. most developers are not even aware of what DVCSes are or what they do. .. The goal right now, if you honestly believe that the DVCS workflow is better—and I do—should be to get the mindset out there, to make more people aware of what DVCSes have to offer and why they should be using them. </quote>
ryanwaggoner 17y ago
It’s easy, in the yin/yang of Hacker News and proggit, to forget that most developers are not even aware of what DVCSes are or what they do. Can this be true? I'm definitely not a rockstar developer and I've been using Git for more than a year.
- gecko 17y ago
  Sadly, yes. I run into them a lot, but always offline. The reason you don't hear about them is because the same people who don't know about DVCSes tend not to frequent forums like Hacker News and proggit. A lot of programmers--and I mean a lot--are just programming to make a buck. Some are good, some are bad, but at any rate, they're not in it for the craft of coding. They're in it because it's a job. Those people don't read the modern equivalent of trade mags because there's nothing in it for them. The only tools that matter are the ones they're actually using, right now. It's these people we really need to reach.
  - ryanwaggoner 17y ago
    It's these people we really need to reach. Hmm...do we? I mean, might the time to try and convince someone like that to switch to Git be better spent elsewhere, like trying to inspire the next generation of programmers who actually code because they love it?
  - mncaudill 17y ago
    Exactly -- commonly called selection bias.
- eli 17y ago
  You'd be surprised how many people still use CVS.
  - pavel_lishin 17y ago
    You'd be surprised by how many don't use any kind of CVS.
maxklein 17y ago
The closer two things are to each other, the more they fight. Like the Hells Angels vs Bandidos, or the Bloods vs the Crips. I mean, coming as someone who is not involved in any crime, it would seem reasonable that the Hells Angels should battle the Crips, seeing as they totally represent different things. But no, they go fight the people closest to them. What I'm trying to say is that Git is like the Hells Angels, Mercurial is like the Bandidos, and SVN is like the Crips. Microsoft Visual Source Safe is like MC Hammer.
- trafficlight 17y ago
  So, are you saying that Visual Source Safe is too legit to quit?
  - Lazlo_Nibble 17y ago
    I think he's saying that when we use Visual SourceSafe, we got to pray // just to make it today.
- raganwald 17y ago
  > The closer two things are to each other, the more they fight. http://en.wikipedia.org/wiki/Narcissism_of_small_differences http://en.wikipedia.org/wiki/Narcissism_of_small_differences
  - pavel_lishin 17y ago
    I figured the reason would be competition for a similar niche.
- StrawberryFrog 17y ago
  Even Microsoft don't use VSS any more, they push TFS.
  - mistermann 17y ago
    I don't think MS ever did use VSS...from what I remember, they used a modified version of.....Mercurial?? Or maybe something else. Can someone else can be more specific?
Maciek416 17y ago
The article hits the nail squarely on the head. Git is pretty awesome, I love using github. From what I've seen of Mercurial, it is also mostly blessed the same awesomeness. Getting people to convert is a fairly big undertaking, though, and although the author touches on this, he might be underestimating the task of conversion a little bit. The first of his 3 points (that git/mercurial's inferior handling of binary files is one of the major issues) is in my opinion dwarfed by an issue he doesn't even mention: git's cryptic user experience and sometimes insanely-scary (especially to git newbies) error messages. I've met plenty of coders who are brilliant programmers but are completely baffled by the very simplest of operations in git when they fail. I'm not sure a better user experience is even remotely on the radar of the folks who work on git, so for git newbies, it's back to svn. Has anyone else noticed this? I'd love to get my day job's project moved from svn to git, given the tremendous benefits (we experience a lot of pain when branching our svn repo), but the pain of moving has to be eased significantly. Moving a repo like ours doesn't just involve importing the repo, it involves training, dealing with all the errors and hangups, figuring out how to make our ancient installation Trac talk to our repo, connecting it to Eclipse and NetBeans, and adjusting all of our build processes. I think if the day to day git experience was less cryptic, we could probably handle the remaining issues.
- weaksauce 17y ago
  What is wrong with using git-svn on your local machine instead of trying to migrate everything over to git?
  - Maciek416 17y ago
    Well, partially my personal ignorance with how that would work :) But also.. my team often has to break into pairs to work on sub-projects and new features, and it would be nice to have everyone on board rather than just a single person. The whole package is compelling. Thanks for the idea though.
    - weaksauce 17y ago
      You're welcome. git-svn is an interface to a svn server that handles the interaction with the svn server. You checkout from the svn server. Do local git stuff and then when you have a completed feature/bugfix you use git-svn to push it back to the svn server. Food for thought at least.
rajat 17y ago
"Their enemy is Subversion" Sigh! Perhaps the enemy is the still surprisingly high number of programmers not using any source code control at all. Perhaps we should be working on educating those who still don't feel the need to use source code control on their own personal projects. But Subversion? I just helped on a "major" project that worked remarkably successfully using good old CVS. I personally prefer Mercurial, and it's what I use for all but my smallest pieces of code, but did CVS work well for coordinating 50+ chip designers, software developers, document writers? Hell yes! Not even a single hiccup, no little thanks to a very helpful and standup IT guy. Good ol' CVS did the job just fine. Could newer technology be better? Yes perhaps I can think of a lot of hypotheticals where it would have been great to have a DVCS, but in practice, I can't think of all that many times where it would have made much of a difference. The fact that every one there, particularly the chip designers, knew how CVS worked, had worked with it for years, had their own work methodologies based on CVS, made the very thought of using anything else nothing but stupid.
weaksauce 17y ago
His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert. How likely is it that Linus will add better support for binary files from an outside project or do we just have to use the forked git?
- nollidge 17y ago
  Haven't used Git or Mercurial at all, so I'm wondering: How does DVCS suck at binary files currently? Does it just not support them or something?
  - weaksauce 17y ago
    It's part of their nature. They store the complete history of the repository by default on your computer. Git does not pack the files by default. I am still figuring out all the innards of Git but I believe that it stores a new copy of the file each time it changes and then hardlinks the tree object to the new file. you can run a pack operation that will create deltas of the files but this is an additional step. Any Git gurus here please correct my understanding of how Git manages binary files.
  - schacon 17y ago
    Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the project. Which means if you've had a lot of big files, you get ALL of them. Also, they don't delta compress well, so that can be a lot, much of which you may never need again, so it's inefficient. For most projects, this isn't a big deal, but if you have a bunch of large texture files or video that MUST be in the project (game development, perhaps), this can be an issue. Subversion is "better" at this only because it does shallow checkouts - it only gets the last version of the project. It is still ludicrously inefficient in it's transfer protocol. Git can actually do this type of development fine - if you do 'git clone --depth=1 [url]' it will also do a shallow clone (just the last commit and it's associated content) and will transfer the data much more efficiently than SVN. In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can. You can also later deepen the repository if you want. It is not an often used feature, but I think it brings Git pretty close to on-par with SVN for large projects, if not better in many respects.
dlsspy 17y ago
It's the sort of next step in the blub problem. People are coming from a world where they see svn as being so much better than cvs (and source safe and what-not), but the only thing close to it in its class is p4, and they have to pay a lot for that, so it doesn't count. Then someone convinces them that there's a better class of things and they want to give it a shot. git users talk about the power and wonders of git. hg users talk about how much easier it is to use than git. bzr jumps up and down slowly and says, "me too!" In this sense, DVCSs are each other's enemies preventing our own adoption. I've used hg a lot and I've been using git almost exclusively for a couple of years. A project whose source is in git is more likely to get contributions from me because it's just easier for me. Projects that use hg will get a contribution if it's a big enough pain because it means more work for me.
sshumaker 17y ago
I've always had this issue with Mercurial - if you're actively developing and want to fetch updates from the upstream, you are forced to check in to your local repo, even if the code you're working on isn't ready to be checked in. Git might do a better job that mercurial with git stash, but mercurial's equivalent (hg shelve) sucks - when you unshelve, rather than generating typical conflict markers, it generates patch diff files, which are way harder to work with. When you're developing with a small team, this happens all the time. After a project wrestling with mercurial, my team forced me to switch back to SVN. I tried using git (with git-svn) to work around this, and even with the easy-git porcelain, the learning curve (and cryptic errors) were ridiculous (basically, easy-git is a pretty leaky abstraction). There's absolutely no reason why a VCS should be that hard to use.
- schacon 17y ago
  btw, if you just run 'git fetch', it will just grab any new commits - it won't modify your working directory or try to merge automatically. i believe 'hg pull' is the same - it just gets the new heads, it doesn't try to merge. you shouldn't need to stash/shelve just to get the new work.
  - sshumaker 17y ago
    Yes, but what use to you are the newer commits unless you bring them into your working directory? Typically you're doing this to get some code to help enable the feature you're working on.
- tghw 17y ago
  The problem is easily solved with smaller, more frequent commits. In SVN, your changes had to be "ready to check in", which was this big, complicated ritual where you back up your changes, update, merge, check to see if the merge screwed with your changes, replace your backed up files, diff, unfuck the merge, and finally, commit. With DVCSs, there's no reason not to commit partially done features. If you're at enough of a stopping point to want to merge in other people's changes, you're at enough of a stopping point to commit what you have so far. Your code only needs to be "ready" when you push it out.
nollidge 17y ago
"It’s easy, in the yin/yang of Hacker News and proggit, to forget that most developers are not even aware of what DVCSes are or what they do." It's also easy, in the yin/yang (what?) of Hacker News and proggit, to forget that there's plenty of developers RIGHT HERE who do not grok DVCS. I sort of know what they are, and that they making branching suck less or something. Hello, I'm nollidge, and I don't get DVCS. Where do I start?
- eru 17y ago
  There are a lot of good tutorials on the net. Just search for them.
- zaphar 17y ago
  Pick one. Start a project in it. Stick with it till you get past the learning curve. Wait for the light bulb to go off. There is really no better way to "get it". It will have some pain at first and you won't understand the benefits immediately but one day when you're coding and suddenly realize that you no longer weigh the pain and risks of creating a branch you'll suddenly wonder how you did without this tool for so long.
- tbrownaw 17y ago
  I started with http://monotone.ca/monotone.html#Concepts http://monotone.ca/monotone.html#Concepts . Git and Mercurial took the same basic history structure and offer roughly the same abilities, but don't make such extensive use of certificates and have slightly different concepts of what a "branch" actually is and how branches relate to repositories and working copies.
- steveklabnik 17y ago
  For me, it was watching Linus' Google talk on git, and then reading some tutorials, and then just doing it. Linus: http://www.youtube.com/watch?v=4XpnKHJAok8 GitReady: http://gitready.com/ Pro Git: http://progit.org/book/ A short little bit about git's internal model: http://eagain.net/articles/git-for-computer-scientists/ GitHub's Git Cheat Sheet: http://github.com/guides/git-cheat-sheet A successful git branching model. gorgeous workflow and pictures. http://nvie.com/archives/323 Also, if you have any questions, feel free to email me. The only reason someone should be using SVN now is if there are institutional reasons or if you use lots of large binary files. I'd rather you send me an email about something that seems hard than give up and use an inferior tool. I'm not an absolute git master, but I've ended up explaining it to most of my classmates, so I've given that explanation a few times already.
aarongough 17y ago
I'll come right out and admit that I still use Subversion. And like it. That seems like a crime to most people because I'm a Rails coder, but the truth is that I haven't had any need of anything else yet. I'm generally the only person working on my projects which means that Subversion meets all my needs. I'm sure that there are benefits to converting, but every time I start the process I get turned off by having to learn a whole new way of doing things... For now: I'm sticking with Subversion.
- thibaut_barrere 17y ago
  I'll second that - for 2 customers, we're just back to SVN, actually (despite I'm using Git for my own projects, because I like to commit offline, mostly). The learning curve of Git is way too steep for non-technical participants in particular, at least in my experience, whereas they seem to handle SVN without much difficulties.
Estragon 17y ago
This kind of thing makes me feel the same way I do about lisp: I've tried both, and I'm still struggling to understand what the hype is about.

90 points by tghw 17y ago

Poor Darcs, it's not even considered. I remember how awesome I thought Darcs was, but now we're almost done switching to Git. I would've stayed, but Git lapped Darcs on tools, performance, and stability. A shame.

pierrefar 17y ago
Why is it a shame that there is a much better product that meets your needs?
- amock 17y ago
  I think it's a shame because Darcs has beautiful theory behind it and is written in my favorite programming language. I feel the same way about some hardware, like the SGI Octane with MIPS processors, dual board graphics cards, and a crossbar architecture. Practically speaking it's worthless because it pulls way too much power and even a cheap netbook is 10 times as fast, but it's still my favorite computer. So it's not a shame that there's a better product, it's a shame that the product I want to be the best isn't.
mbrubeck 17y ago
The author of Darcs is writing a git porcelain that uses the Darcs command-line interface and patch semantics: http://github.com/droundy/iolaus http://github.com/droundy/iolaus
- asnyder 17y ago
  There's also darcs-git, which is a python script that allows you to run darcs command in git. http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-tools.git;a=blob;f=darcs-git.py;hb=HEAD http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-tools.g...

raganwald 17y ago

Odd, but as I was reading this I kept thinking of programming language flame wars: > So why is there so much hating? I think what’s going on is that people are coming to these languages from Java or PHP, have their massive epiphany on how totally awesome these languages are, and then assume that only their language can have this level of awesome, so they begin evangelizing. The problem, of course, is that the other guy feels the same way, and is also evangelizing, so the Ruby and the Python guy end up in a locker-room-style temper-tantrum over whose language has the best frameworks or whatnot, instead of how much more awesome their languages are than the competition. > This has to stop. > Python’s enemy is not Ruby. Ruby’s enemy is not Python. > Their enemy is Java.

d0mine 17y ago

Summary: Mercurial’s enemy is not Git. Git’s enemy is not Mercurial. Their enemy is Subversion. .. most developers are not even aware of what DVCSes are or what they do. .. The goal right now, if you honestly believe that the DVCS workflow is better—and I do—should be to get the mindset out there, to make more people aware of what DVCSes have to offer and why they should be using them. </quote>

ryanwaggoner 17y ago

It’s easy, in the yin/yang of Hacker News and proggit, to forget that most developers are not even aware of what DVCSes are or what they do. Can this be true? I'm definitely not a rockstar developer and I've been using Git for more than a year.

gecko 17y ago
Sadly, yes. I run into them a lot, but always offline. The reason you don't hear about them is because the same people who don't know about DVCSes tend not to frequent forums like Hacker News and proggit. A lot of programmers--and I mean a lot--are just programming to make a buck. Some are good, some are bad, but at any rate, they're not in it for the craft of coding. They're in it because it's a job. Those people don't read the modern equivalent of trade mags because there's nothing in it for them. The only tools that matter are the ones they're actually using, right now. It's these people we really need to reach.
- ryanwaggoner 17y ago
  It's these people we really need to reach. Hmm...do we? I mean, might the time to try and convince someone like that to switch to Git be better spent elsewhere, like trying to inspire the next generation of programmers who actually code because they love it?
- mncaudill 17y ago
  Exactly -- commonly called selection bias.
eli 17y ago
You'd be surprised how many people still use CVS.
- pavel_lishin 17y ago
  You'd be surprised by how many don't use any kind of CVS.

maxklein 17y ago

The closer two things are to each other, the more they fight. Like the Hells Angels vs Bandidos, or the Bloods vs the Crips. I mean, coming as someone who is not involved in any crime, it would seem reasonable that the Hells Angels should battle the Crips, seeing as they totally represent different things. But no, they go fight the people closest to them. What I'm trying to say is that Git is like the Hells Angels, Mercurial is like the Bandidos, and SVN is like the Crips. Microsoft Visual Source Safe is like MC Hammer.

trafficlight 17y ago
So, are you saying that Visual Source Safe is too legit to quit?
- Lazlo_Nibble 17y ago
  I think he's saying that when we use Visual SourceSafe, we got to pray // just to make it today.
raganwald 17y ago
> The closer two things are to each other, the more they fight. http://en.wikipedia.org/wiki/Narcissism_of_small_differences http://en.wikipedia.org/wiki/Narcissism_of_small_differences
- pavel_lishin 17y ago
  I figured the reason would be competition for a similar niche.
StrawberryFrog 17y ago
Even Microsoft don't use VSS any more, they push TFS.
- mistermann 17y ago
  I don't think MS ever did use VSS...from what I remember, they used a modified version of.....Mercurial?? Or maybe something else. Can someone else can be more specific?

Maciek416 17y ago

The article hits the nail squarely on the head. Git is pretty awesome, I love using github. From what I've seen of Mercurial, it is also mostly blessed the same awesomeness. Getting people to convert is a fairly big undertaking, though, and although the author touches on this, he might be underestimating the task of conversion a little bit. The first of his 3 points (that git/mercurial's inferior handling of binary files is one of the major issues) is in my opinion dwarfed by an issue he doesn't even mention: git's cryptic user experience and sometimes insanely-scary (especially to git newbies) error messages. I've met plenty of coders who are brilliant programmers but are completely baffled by the very simplest of operations in git when they fail. I'm not sure a better user experience is even remotely on the radar of the folks who work on git, so for git newbies, it's back to svn. Has anyone else noticed this? I'd love to get my day job's project moved from svn to git, given the tremendous benefits (we experience a lot of pain when branching our svn repo), but the pain of moving has to be eased significantly. Moving a repo like ours doesn't just involve importing the repo, it involves training, dealing with all the errors and hangups, figuring out how to make our ancient installation Trac talk to our repo, connecting it to Eclipse and NetBeans, and adjusting all of our build processes. I think if the day to day git experience was less cryptic, we could probably handle the remaining issues.

weaksauce 17y ago
What is wrong with using git-svn on your local machine instead of trying to migrate everything over to git?
- Maciek416 17y ago
  Well, partially my personal ignorance with how that would work :) But also.. my team often has to break into pairs to work on sub-projects and new features, and it would be nice to have everyone on board rather than just a single person. The whole package is compelling. Thanks for the idea though.
  - weaksauce 17y ago
    You're welcome. git-svn is an interface to a svn server that handles the interaction with the svn server. You checkout from the svn server. Do local git stuff and then when you have a completed feature/bugfix you use git-svn to push it back to the svn server. Food for thought at least.

rajat 17y ago

"Their enemy is Subversion" Sigh! Perhaps the enemy is the still surprisingly high number of programmers not using any source code control at all. Perhaps we should be working on educating those who still don't feel the need to use source code control on their own personal projects. But Subversion? I just helped on a "major" project that worked remarkably successfully using good old CVS. I personally prefer Mercurial, and it's what I use for all but my smallest pieces of code, but did CVS work well for coordinating 50+ chip designers, software developers, document writers? Hell yes! Not even a single hiccup, no little thanks to a very helpful and standup IT guy. Good ol' CVS did the job just fine. Could newer technology be better? Yes perhaps I can think of a lot of hypotheticals where it would have been great to have a DVCS, but in practice, I can't think of all that many times where it would have made much of a difference. The fact that every one there, particularly the chip designers, knew how CVS worked, had worked with it for years, had their own work methodologies based on CVS, made the very thought of using anything else nothing but stupid.

weaksauce 17y ago

His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert. How likely is it that Linus will add better support for binary files from an outside project or do we just have to use the forked git?

nollidge 17y ago
Haven't used Git or Mercurial at all, so I'm wondering: How does DVCS suck at binary files currently? Does it just not support them or something?
- weaksauce 17y ago
  It's part of their nature. They store the complete history of the repository by default on your computer. Git does not pack the files by default. I am still figuring out all the innards of Git but I believe that it stores a new copy of the file each time it changes and then hardlinks the tree object to the new file. you can run a pack operation that will create deltas of the files but this is an additional step. Any Git gurus here please correct my understanding of how Git manages binary files.
- schacon 17y ago
  Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the project. Which means if you've had a lot of big files, you get ALL of them. Also, they don't delta compress well, so that can be a lot, much of which you may never need again, so it's inefficient. For most projects, this isn't a big deal, but if you have a bunch of large texture files or video that MUST be in the project (game development, perhaps), this can be an issue. Subversion is "better" at this only because it does shallow checkouts - it only gets the last version of the project. It is still ludicrously inefficient in it's transfer protocol. Git can actually do this type of development fine - if you do 'git clone --depth=1 [url]' it will also do a shallow clone (just the last commit and it's associated content) and will transfer the data much more efficiently than SVN. In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can. You can also later deepen the repository if you want. It is not an often used feature, but I think it brings Git pretty close to on-par with SVN for large projects, if not better in many respects.

dlsspy 17y ago

It's the sort of next step in the blub problem. People are coming from a world where they see svn as being so much better than cvs (and source safe and what-not), but the only thing close to it in its class is p4, and they have to pay a lot for that, so it doesn't count. Then someone convinces them that there's a better class of things and they want to give it a shot. git users talk about the power and wonders of git. hg users talk about how much easier it is to use than git. bzr jumps up and down slowly and says, "me too!" In this sense, DVCSs are each other's enemies preventing our own adoption. I've used hg a lot and I've been using git almost exclusively for a couple of years. A project whose source is in git is more likely to get contributions from me because it's just easier for me. Projects that use hg will get a contribution if it's a big enough pain because it means more work for me.

sshumaker 17y ago

I've always had this issue with Mercurial - if you're actively developing and want to fetch updates from the upstream, you are forced to check in to your local repo, even if the code you're working on isn't ready to be checked in. Git might do a better job that mercurial with git stash, but mercurial's equivalent (hg shelve) sucks - when you unshelve, rather than generating typical conflict markers, it generates patch diff files, which are way harder to work with. When you're developing with a small team, this happens all the time. After a project wrestling with mercurial, my team forced me to switch back to SVN. I tried using git (with git-svn) to work around this, and even with the easy-git porcelain, the learning curve (and cryptic errors) were ridiculous (basically, easy-git is a pretty leaky abstraction). There's absolutely no reason why a VCS should be that hard to use.

schacon 17y ago
btw, if you just run 'git fetch', it will just grab any new commits - it won't modify your working directory or try to merge automatically. i believe 'hg pull' is the same - it just gets the new heads, it doesn't try to merge. you shouldn't need to stash/shelve just to get the new work.
- sshumaker 17y ago
  Yes, but what use to you are the newer commits unless you bring them into your working directory? Typically you're doing this to get some code to help enable the feature you're working on.
tghw 17y ago
The problem is easily solved with smaller, more frequent commits. In SVN, your changes had to be "ready to check in", which was this big, complicated ritual where you back up your changes, update, merge, check to see if the merge screwed with your changes, replace your backed up files, diff, unfuck the merge, and finally, commit. With DVCSs, there's no reason not to commit partially done features. If you're at enough of a stopping point to want to merge in other people's changes, you're at enough of a stopping point to commit what you have so far. Your code only needs to be "ready" when you push it out.

nollidge 17y ago

"It’s easy, in the yin/yang of Hacker News and proggit, to forget that most developers are not even aware of what DVCSes are or what they do." It's also easy, in the yin/yang (what?) of Hacker News and proggit, to forget that there's plenty of developers RIGHT HERE who do not grok DVCS. I sort of know what they are, and that they making branching suck less or something. Hello, I'm nollidge, and I don't get DVCS. Where do I start?

eru 17y ago
There are a lot of good tutorials on the net. Just search for them.
zaphar 17y ago
Pick one. Start a project in it. Stick with it till you get past the learning curve. Wait for the light bulb to go off. There is really no better way to "get it". It will have some pain at first and you won't understand the benefits immediately but one day when you're coding and suddenly realize that you no longer weigh the pain and risks of creating a branch you'll suddenly wonder how you did without this tool for so long.
tbrownaw 17y ago
I started with http://monotone.ca/monotone.html#Concepts http://monotone.ca/monotone.html#Concepts . Git and Mercurial took the same basic history structure and offer roughly the same abilities, but don't make such extensive use of certificates and have slightly different concepts of what a "branch" actually is and how branches relate to repositories and working copies.
steveklabnik 17y ago
For me, it was watching Linus' Google talk on git, and then reading some tutorials, and then just doing it. Linus: http://www.youtube.com/watch?v=4XpnKHJAok8 GitReady: http://gitready.com/ Pro Git: http://progit.org/book/ A short little bit about git's internal model: http://eagain.net/articles/git-for-computer-scientists/ GitHub's Git Cheat Sheet: http://github.com/guides/git-cheat-sheet A successful git branching model. gorgeous workflow and pictures. http://nvie.com/archives/323 Also, if you have any questions, feel free to email me. The only reason someone should be using SVN now is if there are institutional reasons or if you use lots of large binary files. I'd rather you send me an email about something that seems hard than give up and use an inferior tool. I'm not an absolute git master, but I've ended up explaining it to most of my classmates, so I've given that explanation a few times already.

aarongough 17y ago

I'll come right out and admit that I still use Subversion. And like it. That seems like a crime to most people because I'm a Rails coder, but the truth is that I haven't had any need of anything else yet. I'm generally the only person working on my projects which means that Subversion meets all my needs. I'm sure that there are benefits to converting, but every time I start the process I get turned off by having to learn a whole new way of doing things... For now: I'm sticking with Subversion.

thibaut_barrere 17y ago
I'll second that - for 2 customers, we're just back to SVN, actually (despite I'm using Git for my own projects, because I like to commit offline, mostly). The learning curve of Git is way too steep for non-technical participants in particular, at least in my experience, whereas they seem to handle SVN without much difficulties.

Estragon 17y ago

This kind of thing makes me feel the same way I do about lisp: I've tried both, and I'm still struggling to understand what the hype is about.