It depends. I make complex merges/branches on a regular basis and I find myself using `commit -a` pretty often, but I am also diligently branching out whenever I start working on something different, so I'm often confident that all the files that are both tracked and modified are the ones I want to commit.
blasedl:
I think that `git add -p` (committing certain changes in a file but not others) is a pretty advanced feature. I can see how it can be a life saver for experienced users, but I recommend creating two branches with each 100% of your changes rather than using just one branch that contains 60% and 40% of your changes.
One switch that I find very useful is `git add -i`, which you should use whenever you want to add 2 files but you have 20 untracked ones in your working directory.
add -p is barely advanced at all. It's certainly less advanced than merging the conflicts between pointless local branches and dealing with the existence of modified files in the working copy when switching between them.
I find commit -am to be more infantile than rebase is advanced. Don't try to pretend that the index doesn't exist, since it will get dropped in your lap eventually, most likely when you least want it to (failed merge, etc).
In the above mentioned cleanup procedure, one of my developers was convinced that git would commit all changes during an interactive rebase where he was splitting a changeset regardless of what he had staged.
I asked him the exact commands he used:
git rebase -i whatever
# select a thing to edit and split
git add -p # ...
git commit
git rebase --continue
Said it never split his change. Then I saw his transcript -- it included "git commit -a" Apparently he got so used to typing that that he just instinctively placed "-a" at the end of "git commit" because that's how you do it.
I'm pretty sure he wasted hours with the magic -a option (not counting the ones that required the commits to be split up in the first place).
It depends. I make complex merges/branches on a regular basis and I find myself using `commit -a` pretty often, but I am also diligently branching out whenever I start working on something different, so I'm often confident that all the files that are both tracked and modified are the ones I want to commit.
blasedl:
I think that `git add -p` (committing certain changes in a file but not others) is a pretty advanced feature. I can see how it can be a life saver for experienced users, but I recommend creating two branches with each 100% of your changes rather than using just one branch that contains 60% and 40% of your changes.
One switch that I find very useful is `git add -i`, which you should use whenever you want to add 2 files but you have 20 untracked ones in your working directory.