[pseut]

I think 'git add -p .' would have worked better for the specific example he gave, though. (Step through and stage change by change)

[tmoertel]

The reason I don't use `git add -p` to incrementally approve the "good" changes is that the sledgehammer is not incremental: it expects to be applied to the original clean slate. Using git stash will get me back to that clean slate. Using `git add -p` will not, for both the approved and unapproved changes will remain in the working tree, where the sledgehammer expects neither of them to be.

[pseut]

Getting back to the clean slate is pretty trivial whatever you do, which is one of the nice things about git. I'd probably prefer to have a main (sub) branch that I add to incrementally, apply various sledgehammers to the "clean slate" and rebase the results of the sledgehammer liberally.

[ibotty]

as i said in my other comment. that will only work for idempotent things: if you like to change, say, ' to ", the workflow in the article works, but git add -p won't.

[pseut]

I don't follow you. Any time I'm inspecting the diff to see if I made the change I want, staging the changes i want progressively and then discarding the rest has worked well.

[ibotty]

the important part missing in my example is the 'vice versa'. the canonical example is:

> sledge() { tr ab ba < $1 | sponge $1 }

then, you might undo a change you already -p added.

more convincing might be (using gnu sed):

> sledge() { sed -i s/identifier/long_identifier/ $1 }

a second iteration will eventually generate long_long_identifier.