Mina Almasry <almasry.mina@xxxxxxxxxxx> writes: > I frequently stage files using git add --patch command and I almost > always come across debug code I want to discard, but there is no option > for that in the prompt. The result is that I have to run an extra > command after the dialogue ends. > > I would like to add a feature to allow users to discard hunks using a > command like r! or d! This has come up before, and actually led to the introduction of 'checkout -p' and 'reset -p': http://thread.gmane.org/gmane.comp.version-control.git/123854 Judging by the '!' above, you are already aware that this is a dangerous option that needs some safeguards. I imagine that would largely account for Junio's safety concerns. So you could pick up from the general direction of Pierre's post, and try to work out something. However, life has become rather more complicated since 2009. Whatever you do also needs to fit nicely with checkout/reset/stash -p. The first two also take commit arguments, resulting in a total of seven modes of operation, defined in %patch_modes. I imagine one good angle of attack would be to proceed as follows: * Optionally make add--interactive.perl more aware of what the patches say. Ideally there would be a way to reverse the direction of a diff (or otherwise manipulate it) in the program itself, instead of having to decide this when fetching the patches. * Change things so that the actions in %patch_modes are a hunk property instead of a global state. Of course the actual mode still needs to be global state. Not all actions should be possible in all modes; figure out a clean way to implement this. * Design commands in some modes that switch to another mode, and/or set another action than the default in the current mode. Note that r! commands need to also work in singlekey mode, where the 'r' is read immediately and you would have to read for another (confirmation) key to get the '!'. Good luck! -- Thomas Rast trast@{inf,student}.ethz.ch -- 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