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
commit).
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".
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html