4 ms·

The lack of a staging area is the deal breaker for me.

doubleunplussed 7y ago
Mercurial does have a staging area. It just defaults to including all previously-committed files, which IMHO is very sensible. Link to my previous comment on it: https://news.ycombinator.com/item?id=21393972 https://news.ycombinator.com/item?id=21393972
- jcranmer 7y ago
  What you describe is not a staging area, it is an interactive commit. And, personally, I see no positive value in a staging area, given that you can achieve the same functionality via interactive commits or amending commits.
  - doubleunplussed 7y ago
    Ah, fair enough. So I suppose git's staging area has the additional benefit that you can stage some things and then shut your computer down and the staging will be there when you come back. I have no idea whether tortoisehg remembers the state of what you've selected in its 'interactive commit' GUI, because I've only ever made those decisions when committing. Given I've been using it almost daily for about six years on a community project (i.e. not just linear commits by a single dev who doesn't need to care about anyone else), I think this is also evidence that a persistent staging area isn't super important.
  - gpderetta 7y ago
    staging interacts with other commands as well. You can stage a bunch of stuff then revert or stash the rest, you can stash everything in the staging area, you can diff only stuff in the staging area and so on. It basically acts as a clipboard. Possibly hg interactive commits work in the same way, but then I do not know how that would be different from a staging area.
    - pseudalopex 7y ago
      Using commits for staging needs fewer different commands and prevents accidentally resetting or discarding changes.
TimTheTinker 7y ago
Agreed. Git's stage provides more flexibility when committing - I'm not constrained to either commit, stash, or revert every modified file. I can choose which modified files I'd like to include in the commit, and the others can be left as-is. It's very nice to have when I've done a lot of work that most naturally should be split into more than one commit, or when I have temporary modifications (say, to config files) that I'd like to leave in place for now but not include as part of the commit.
- yjftsjthsd-h 7y ago
  I'm confused. So say we have a repo that contains only 3 files, foo, bar, and baz. We modify all 3 files but for 2 unrelated reasons. In git, you could do this as `git add foo ; git add bar ; git commit`. But you could also just `git commit foo bar ; git commit baz`. And in mercurial, `hg commit foo bar ; hg commit baz` works fine. Am I misunderstanding what you want to do?
  - hamandcheese 7y ago
    Sometimes I might stage only part of the changes in a single file. Sometimes I want to stage a file or two, see what’s remaining, and decide what else should be in this particular commit. I can and do diff only staged changes, then diff only unstaged changes, to decide how to proceed. Sometimes I unstage certain changes if I decide that no, they in fact should not be in this next commit. Basically, it’s a scratchpad that’s gives me space to think and plan.
    - ansible 7y ago
      Agreed. After getting used to that model for building up a particular commit, I wouldn't want to go back to the mercurial way. I used to use mercurial back in the day, before git took over the planet. Switching back to it would be slightly analogous to switching keyboard layouts at this point. Sure, qwerty is arbitrary and sort of stupid, but I've spent so much time using it that I've gotten used to where everything is.
    - ygra 7y ago
throw0101a 7y ago
Would Hg's queues be an useful equivalent? * http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu...

Mercurial does have a staging area. It just defaults to including all previously-committed files, which IMHO is very sensible. Link to my previous comment on it: https://news.ycombinator.com/item?id=21393972 https://news.ycombinator.com/item?id=21393972

jcranmer 7y ago
What you describe is not a staging area, it is an interactive commit. And, personally, I see no positive value in a staging area, given that you can achieve the same functionality via interactive commits or amending commits.
- doubleunplussed 7y ago
  Ah, fair enough. So I suppose git's staging area has the additional benefit that you can stage some things and then shut your computer down and the staging will be there when you come back. I have no idea whether tortoisehg remembers the state of what you've selected in its 'interactive commit' GUI, because I've only ever made those decisions when committing. Given I've been using it almost daily for about six years on a community project (i.e. not just linear commits by a single dev who doesn't need to care about anyone else), I think this is also evidence that a persistent staging area isn't super important.
- gpderetta 7y ago
  staging interacts with other commands as well. You can stage a bunch of stuff then revert or stash the rest, you can stash everything in the staging area, you can diff only stuff in the staging area and so on. It basically acts as a clipboard. Possibly hg interactive commits work in the same way, but then I do not know how that would be different from a staging area.
  - pseudalopex 7y ago
    Using commits for staging needs fewer different commands and prevents accidentally resetting or discarding changes.

TimTheTinker 7y ago

Agreed. Git's stage provides more flexibility when committing - I'm not constrained to either commit, stash, or revert every modified file. I can choose which modified files I'd like to include in the commit, and the others can be left as-is. It's very nice to have when I've done a lot of work that most naturally should be split into more than one commit, or when I have temporary modifications (say, to config files) that I'd like to leave in place for now but not include as part of the commit.

yjftsjthsd-h 7y ago
I'm confused. So say we have a repo that contains only 3 files, foo, bar, and baz. We modify all 3 files but for 2 unrelated reasons. In git, you could do this as `git add foo ; git add bar ; git commit`. But you could also just `git commit foo bar ; git commit baz`. And in mercurial, `hg commit foo bar ; hg commit baz` works fine. Am I misunderstanding what you want to do?
- hamandcheese 7y ago
  Sometimes I might stage only part of the changes in a single file. Sometimes I want to stage a file or two, see what’s remaining, and decide what else should be in this particular commit. I can and do diff only staged changes, then diff only unstaged changes, to decide how to proceed. Sometimes I unstage certain changes if I decide that no, they in fact should not be in this next commit. Basically, it’s a scratchpad that’s gives me space to think and plan.
  - ansible 7y ago
    Agreed. After getting used to that model for building up a particular commit, I wouldn't want to go back to the mercurial way. I used to use mercurial back in the day, before git took over the planet. Switching back to it would be slightly analogous to switching keyboard layouts at this point. Sure, qwerty is arbitrary and sort of stupid, but I've spent so much time using it that I've gotten used to where everything is.
  - ygra 7y ago

throw0101a 7y ago

Would Hg's queues be an useful equivalent? * http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu...