5 ms·

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 peo

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.)

enzanki_ars 9y ago
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.
- therein 9y ago
  Same here, I actually find `git add -p` to be very useful.
  - masklinn 9y ago
    commit also has a -p flag.
    - tome 9y ago
      Oh wow. No need for me to use git add ever again! EDIT: I suppose I have to use it to add new files :)
      - akx 9y ago
        Just use `git add -i` to mix and match :)
nhaehnle 9y ago
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.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- jwilk 9y ago
  You probably want "git add -N"; otherwise "git diff" won't work as expected.
txdv 9y ago
If you consider the use case "linux kernel development", you realize that you really don't want to automatically commit all your changes.
- TickleSteve 9y ago
  ...and why is kernel development any different to any other large scale project?
- carussell 9y ago
  I do consider the LKML-centric use case. (Often—probably more often than most.) No such realization is setting in. How about you elaborate?
uiri 9y ago
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.
- masklinn 9y ago
  > 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
  - uiri 9y ago
    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.
    - masklinn 9y ago
      > 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.
wutbrodo 9y ago
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).

enzanki_ars 9y ago

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.

therein 9y ago
Same here, I actually find `git add -p` to be very useful.
- masklinn 9y ago
  commit also has a -p flag.
  - tome 9y ago
    Oh wow. No need for me to use git add ever again! EDIT: I suppose I have to use it to add new files :)
    - akx 9y ago
      Just use `git add -i` to mix and match :)

nhaehnle 9y ago

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.

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
jwilk 9y ago
You probably want "git add -N"; otherwise "git diff" won't work as expected.

txdv 9y ago

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

TickleSteve 9y ago
...and why is kernel development any different to any other large scale project?
carussell 9y ago
I do consider the LKML-centric use case. (Often—probably more often than most.) No such realization is setting in. How about you elaborate?

uiri 9y ago

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.

masklinn 9y ago
> 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
- uiri 9y ago
  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.
  - masklinn 9y ago
    > 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.

wutbrodo 9y ago

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).