5 ms·

There's a good chance the person you are replying uses git commit --amend all the time to modify commits in conjunction with git add -p. No, hg amend -i is muc

by sagarm 5y ago

There's a good chance the person you are replying uses git commit --amend all the time to modify commits in conjunction with git add -p. No, hg amend -i is much worse than git add -p. I do that when I have to use mercurial and there's significantly more mental overhead to make sure I'm not accidentally modifying a commit I did not intend to modify. Creating a "temporary" commit before I have a complete change is also annoying. And once you need to add a file, you're back to having a staging-like concept. IMO the staging area is fundamental complexity.

jcranmer 5y ago
Perhaps it's a difference in workflow, but I really don't understand why managing a "temporary" commit is so mentally taxing. Especially because in my workflows, I'm often not managing a single commit but an entire stack of commits, for which the staging area adds no value. As I see it, the staging area is useless because it's basically a weird not-quite-commit-thing that you are more or less required to deal with (no way to opt out of it--several commands end up mucking about with the staging area even if you're not trying to use it). It feels like the better way to model it is to make it an actual commit, let it be manipulated as a regular commit, and then potentially improve the tooling around manipulating unpublished head commits as well.
- feoren 5y ago
  Agreed. If you want to commit something that's not "reviewable" yet, just put it on another branch. Get used to committing things that aren't done yet! Hg does it right.
sushisource 5y ago
OK, then rebase and squash after making a bunch of commits. I can see why someone might like staging, but clearly it can be built on top of other git functions. So, sorry, staging being "fundamental complexity" sounds petty BS to me. You like it, and that's fine, but it's in no way fundamental. I've used git for a long, long time, tried staging a few times and have never reached for it again.
- sagarm 5y ago
  What about hg add (or git add)? Does that not "stage" an addition for the next commit?

by sagarm 5y ago

jcranmer 5y ago

Perhaps it's a difference in workflow, but I really don't understand why managing a "temporary" commit is so mentally taxing. Especially because in my workflows, I'm often not managing a single commit but an entire stack of commits, for which the staging area adds no value. As I see it, the staging area is useless because it's basically a weird not-quite-commit-thing that you are more or less required to deal with (no way to opt out of it--several commands end up mucking about with the staging area even if you're not trying to use it). It feels like the better way to model it is to make it an actual commit, let it be manipulated as a regular commit, and then potentially improve the tooling around manipulating unpublished head commits as well.

feoren 5y ago
Agreed. If you want to commit something that's not "reviewable" yet, just put it on another branch. Get used to committing things that aren't done yet! Hg does it right.

sushisource 5y ago

OK, then rebase and squash after making a bunch of commits. I can see why someone might like staging, but clearly it can be built on top of other git functions. So, sorry, staging being "fundamental complexity" sounds petty BS to me. You like it, and that's fine, but it's in no way fundamental. I've used git for a long, long time, tried staging a few times and have never reached for it again.

sagarm 5y ago
What about hg add (or git add)? Does that not "stage" an addition for the next commit?