Hacker News Reader

Comment by carussell | Hacker News Reader

Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit.

It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with it is an opt-in decision for the 5% of the time that you need to make sure you aren't committing all of your changes. (And on note #2, if a person is doing partially staged changes more often than that, my question is why? What kind of chaotic, stream-of-consciousness style of development leads to that, and is it even producing good results? It doesn't take especially careful planning to not end up in the scenarios where partially committed changes is the answer.)

View on HN

Often I'll work on a large change and make sure that it is working before I start crafting my commits. By the time I get to that point, I realize that I've actually made three separate subchanges so I do partial stages to create each commit.

I use git status -s and git diff quite a bit as a sanity check (for things like whitespace) and to do first party code review before I send anything out.

The staging area is a core part of my personal git workflow pre-commit. It seems to be producing good results so far.

> I realize that I've actually made three separate subchanges so I do partial stages to create each commit.

You can trivially replicate that without staging by amending the HEAD commit, or building a bunch of partial commits then folding them with rebase -i. You can even do that automatically by committing with --fixup or --squash

That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit. Splitting a single big commit into multiple smaller commits with an interactive rebase is dependent upon the staging area too.

> That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit.

Errr… no you're not. `commit -p` exists.

I have ADHD, so often as I am working on one feature, I will begin accidentally working on another unrelated feature along side it. I rely on staging a lot to ensure that each commit has only the parts that it needs.

Same here, I actually find `git add -p` to be very useful.

commit also has a -p flag.

Oh wow. No need for me to use git add ever again!

EDIT: I suppose I have to use it to add new files :)

Just use `git add -i` to mix and match :)

For my first couple _years_ with Git, I just passed the -a flag in upon every commit. This is a pretty easy, low effort habit to form, so this reduces to a question of which default to set. Git's approach seems to be that the default should be to nudge users toward power usage, which I don't think is necessarily a bad thing. (Note that git's approach to defaults in other areas, like potentially destructive actions, is actually a problem).

If you consider the use case "linux kernel development", you realize that you really don't want to automatically commit all your changes.

...and why is kernel development any different to any other large scale project?

I do consider the LKML-centric use case. (Often—probably more often than most.) No such realization is setting in. How about you elaborate?

Git doesn't actually make people deal with staging for every commit, though.

It's quite common to tell newcomers to always `git commit -a`, and `git add` for adding new files. That's pretty much exactly where SVN is/was, and nobody complained about that being complicated or onerous either.

You probably want "git add -N"; otherwise "git diff" won't work as expected.

Reply on news.ycombinator.com