2 ms·

I agree with that. However, if you been making intermediate checkins, it's more difficult to cherry-pick changes to push upstream. Especially if you've been d

I agree with that. However, if you been making intermediate checkins, it's more difficult to cherry-pick changes to push upstream. Especially if you've been doing lots of intermediate checkins - it's easy to forget which changes were intended to be real (as opposed to dummy code you've put in for testing, etc), and push selectively. Maybe this is easier in Git, but it has the worst interface I've ever seen, and that's saying a lot.

tghw 17y ago
If you're considering cherry-picking, you're still thinking in an SVN mindset. We did the exact same thing for a while before figuring it out, with some help from a few people who had used DVCS longer. You just have to use it for a while and you'll start to see the workflow where this isn't a problem.
- sshumaker 17y ago
  We used mercurial for almost a year before the team rebelled and forced a switch back to SVN. :) It was all of our first experience with a DVCS. It's not just cherry picking - if you've spread changes across multiple commits, it's much more difficult to manage them. Yes, you can diff cross revisions. But that's more awkward. Worse - if you commit so you can merge in changes from the mainline, all of your changes get lumped together - which may be logically different fixes - and some may even be debugging code that definitely shouldn't end up in the mainline. If you later need to push a subset of your changes, you're in for a world of hurt. I guess if you get people to use patch queues religiously, you can work around this. But patch queues (in mercurial at least) are definitely rough around the edges, and have their own share of problems. I'm guessing this process is better in Git. But if I can't deal with the interface, there's no way I'm going to convince the rest of the team to do so. If people have suggestions on how to deal with this kind of stuff, I'd love to hear people's suggestions. My HN username @ gmail.

tghw 17y ago

If you're considering cherry-picking, you're still thinking in an SVN mindset. We did the exact same thing for a while before figuring it out, with some help from a few people who had used DVCS longer. You just have to use it for a while and you'll start to see the workflow where this isn't a problem.

sshumaker 17y ago
We used mercurial for almost a year before the team rebelled and forced a switch back to SVN. :) It was all of our first experience with a DVCS. It's not just cherry picking - if you've spread changes across multiple commits, it's much more difficult to manage them. Yes, you can diff cross revisions. But that's more awkward. Worse - if you commit so you can merge in changes from the mainline, all of your changes get lumped together - which may be logically different fixes - and some may even be debugging code that definitely shouldn't end up in the mainline. If you later need to push a subset of your changes, you're in for a world of hurt. I guess if you get people to use patch queues religiously, you can work around this. But patch queues (in mercurial at least) are definitely rough around the edges, and have their own share of problems. I'm guessing this process is better in Git. But if I can't deal with the interface, there's no way I'm going to convince the rest of the team to do so. If people have suggestions on how to deal with this kind of stuff, I'd love to hear people's suggestions. My HN username @ gmail.