4 ms·
I think 'git add -p .' would have worked better for the specific example he gave, though. (Step through and stage change by change)
by pseut 14y ago
I think 'git add -p .' would have worked better for the specific example he gave, though. (Step through and stage change by change)
- ibotty 14y agoas 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 14y agoI 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 14y agothe 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.
- tmoertel 14y agoThe 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 14y agoGetting 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.