Making clean commits from a mess of changes in the working tree

Question

Sometimes I end up with a working tree with a lot of changes, mainly after coding in a hurry - the changes are so many that could fit in 20 commits, spread across 2 or three branches. To clean up the working tree and commit everything nicely, I follow this unpleasant workflow:

1. Use git add -p to inspect all the hunks in the working tree, without saving anything to the index (i.e. answer "no, don't stage this" to every hunk). Meanwhile, I try to mentally group the hunks into commits, and take some notes (in a text file) of the commits I should build with the hunks I'm seeing.

2. After I've assigned every hunk to a commit (in my notes), then I start git add -p again, and answer "yes, stage this" only to the hunks that go into the first commit. After going over all the hunks and picking the ones I want, I actually do the commit.

3. Repeat at step 2 as long as there are hunks left in git add -p. This means that I go over all the hunks, for every commit I have in my notes.

This is obviously a very silly way of dealing with many changes at once. Is there a good way of starting with many changes, sorting them out and then ending up with a nice set of commits, in their right branches?

Maybe there is a way to incrementally build multiple commits, simultaneously, in multiple indexes. Or maybe I should commit all the changes into one big commit, then split it into multiple ones somehow? Or maybe there's a way to (ab)use git stash to help in grouping changes together?

Answer 1

Not much of an improvement, but you could start adding files to the first commit during step one, even if that does not end up to be the first commit you really want to have, since you can finish by reordering your commits with an interactive rebase.

Answer 2

You are going against the typical workflow of git add

It typically adds the current content of existing paths as a whole, but
with some options it can also be used to add content with only part of
the changes made to the working tree files applied.

git add -p is there to "bail you out", but you should not be repeatedly using this workflow to where you need multiple indexes to accomodate it. Use Git as it is meant to be used.

Answer 3

If you can slightly modify your workflow such that:

1. you have multiple 'features' implemented in multiple files, but
2. you don't have multiple 'features' implemented in one file

then you could use:

git commit -m 'feature 1' -- foo.c bar.c
git commit -m 'feature 2' -- bing.c bang.c
...

This avoids the entire 'hunk' problem - but it requires you to change your workflow.

Note that the 'git way' for this is to create a branch for each feature, to develop each feature independently, to merge all the features back in.