4 ms·

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

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.
- sshumaker 17y ago
  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.
100k 17y ago
You can get around this some of the time with hg pull; hg up (instead of hg fetch). This works as long as you don't have a conflict. If you have a conflict you have to check in and merge at that point. I do agree that git stash is superior to the hg alternatives.
- sshumaker 17y ago
  Yes - but sometimes there are conflicts. Often they're totally trivial - but it's very strange that my workflow gets altered - forcing me to checkin unfinished work - based on whether or not some other programmer's change happens to conflict with what I'm working on.

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.

sshumaker 17y ago
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.

100k 17y ago

You can get around this some of the time with hg pull; hg up (instead of hg fetch). This works as long as you don't have a conflict. If you have a conflict you have to check in and merge at that point. I do agree that git stash is superior to the hg alternatives.

sshumaker 17y ago
Yes - but sometimes there are conflicts. Often they're totally trivial - but it's very strange that my workflow gets altered - forcing me to checkin unfinished work - based on whether or not some other programmer's change happens to conflict with what I'm working on.