3 ms·

I'm sorry, but this last point simply isn't true. Sometimes I'll be building a new feature, and I'll expose a bug which another dev will fix and check in, or a

I'm sorry, but this last point simply isn't true. Sometimes I'll be building a new feature, and I'll expose a bug which another dev will fix and check in, or another dev will add some hooks for me. The new feature definitely isn't ready to check-in, but I need to get their changes to continue.

tghw 17y ago
That's my point, this "ready" concept is just a holdover from SVN. There's no reason a commit has to be "ready" in any way. You can even say that in the commit message.
- sshumaker 17y ago
  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.
- astine 17y ago
  To finish the thought, you only have to commit to your local repo. No one has to see the unfinished code. The only place where this would cause a problem is where you want to roll back only to 'good' commits. Git, at least, lets you merge commits and erase 'unfinished' commits.

tghw 17y ago

That's my point, this "ready" concept is just a holdover from SVN. There's no reason a commit has to be "ready" in any way. You can even say that in the commit message.

sshumaker 17y ago
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.
astine 17y ago
To finish the thought, you only have to commit to your local repo. No one has to see the unfinished code. The only place where this would cause a problem is where you want to roll back only to 'good' commits. Git, at least, lets you merge commits and erase 'unfinished' commits.