On Thu, Jul 23, 2009 at 12:58:06PM -0700, Junio C Hamano wrote: > Pierre Habouzit <madcoder@xxxxxxxxxx> writes: > > > One of my most frequent use case for git-add -p is when I had an intense > > debug session with quite a lot of debug() traces added. I then want only > > to select the hunks corresponding to the bugfixes and throw away the debug > > ones. > > I do not particularly like this change. "add -i", "add -p" and "add" in > general are about manipulating the index. They are never meant to touch > the work tree contents. Which means that even if you make a mistake in > saying y/n, you won't damange the state you have in your work tree, and > also means that you can recover safely by simply restarting "add -p" > session if you really botched splitting of the patch. Okay, fair enough, this is kind of mixing stuff together, I reckon. OTOH this fills out a real need: sorting out the debug code from the non debug one, it's particularily handy, and many people at work here have applied my patch and it saves them lots of time. So maybe we should see how to have a new command like git hunk-sort or git hunk-triage or whatever, I don't really mind. Another way, that is non destructive is to _not_ apply the reverting patch, but only to generate it, and let the user apply it himself. E.g. something along the lines of: $ git add -p ... select your patches ... info: you have selected hunks for removal from you tree info: run the following command to make them go away: git apply -R --recount git-add-undo-12asWED.patch $ And let the user cut & paste the command. _I_ could live with that, and you lose the dangerous factor. -- Intersec <http://www.intersec.com> Pierre Habouzit <pierre.habouzit@xxxxxxxxxxxx> Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie -- 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