Re: [PATCH] git-add -p: be able to undo a given hunk

[Pierre Habouzit <madcoder@madism.org>]

On Thu, Jul 23, 2009 at 12:58:06PM -0700, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> 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@intersec.com>
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