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

Reply via email to