On Thu, Nov 08, 2012 at 12:57:19AM -0800, Jonathon Mah wrote:
> I find myself performing similar actions to you: using git add -p to
> stage hunks, sometimes editing the staged patch; and keeping mental
> notes of things I wanted to revert, sometimes changing them in the
> editor in another window, and sometimes reverting them after the add
> session with git checkout -p).
Yeah, I often use a similar workflow. A related one is:
(1) Make lots of unrelated changes in the working tree.
$ hack hack hack
(2) Pick out hunks for the first commit.
$ git add -p
(3) Put the rest of the changes aside.
$ git stash -k
(4) Test (and possibly tweak) the result, then commit.
$ make test
$ git commit -m "topic 1"
(5) Bring back the stashed changes.
$ git stash pop
(6) If there are still interesting changes, goto step 2.
(7) Otherwise, discard with "git reset --hard" or "git checkout -p".
I.e., iterating on the changes to put them into several different
commits (and achieving a clean, testable state before making each
The downside of these workflows is that you have to say "no" to hunks
multiple times (one per iteration) instead of just sorting them in a
single pass. This works OK in practice, but it might be nice to have a
tool that makes a single pass and lets you drop hunks into buckets
(topic 1 vs topic 2 vs discard), and then apply the buckets in order,
stopping to test, tweak, and commit after each one.
> The interactive staging-and-editing tool could be improved, but I'm
> not sure that tool should be called 'git add -p'. git add doesn't
> touch the working tree — at least I hope not, because I wouldn't
> expect it.
Right. I think the idea of one-pass tool is a good one, but it should
not be called "git add -p".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html