Hacker News Reader

Comment by jcranmer | Hacker News Reader

> The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…)

Are you aware that git commit --amend exists? That replaces anything I might ever be tempted to use the staging area for.

View on HN

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.

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.

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.

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.

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

I'm not sure how you use --amend to do partial commits of a file.

Well, that would be solved with --interactive, would it not?

"git commit" takes the -p (or --patch) flag for partial commits of a file, just like "git add". (Some people prefer --interactive, but I think the patch mode is significantly superior.)

So I'm working and committing as I go along instead of staging, I need to be super sure I only rebase and never pull or else I've made a huge mess?

I think I'll stick with staging.

Reply on news.ycombinator.com