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

Nanako Shiraishi <nanako3@lavabit.com> writes:

It is true that as new people learn they gain proficiency, and you are also right to point out that I'd usually choose to optimize the interface for making the life of experts easier rather than welding training wheels to the system.

BUT

As new people gain proficiency in git, three things happen.

 (1) It becomes a lot less likely for them to make mistakes in choosing
     commands.  I mentioned that they may misunderstand what Pierre's
     "undo" would do, and that fear may be alleviated because of this.

 (2) It does _not_ become less likely for them to make typos when giving
     the command they chose.  The chance of saying 'u' when you mean 'y'
     does not decrease that much as you become more used to using git.
     Especially with interactive.singlekey, the consequence of such a typo
     is devastating.

 (3) They form a better mental model of how the world works.

     The high level view of the git workflow is for you to:

     (a) prepare good changes, together with some changes that are not
         quite ready, in your work tree; and

     (b) use "git add" to add only good changes suitable for the next
         commit to the index; and finally

     (c) make the next commit out of the index.  Repeat (b) and (c) as
         necessary to create multiple commits.

     If you botch the "git add" step during this process, because "git
     add" promises not to touch the work tree, you can safely reset the
     index entry to its previous state and redo the "git add" step,
     without having to fear that you may lose your work.

In your arsenal, you have "git add -p" to help you sift good pieces from other parts in finer grained manner, instead of having to make an all or nothing decision per file basis (i.e. "git add file"). But "git add -p" (and "git add -i") is still about the "git add" step in the above high level view. You have a mixture of good and not so good changes in your work tree, and you pick only good pieces to add to the index, _knowing_ that you can go back and redo this step safely exactly because your work tree will stay the same even if you did make mistakes.

The proposed change breaks this expectation you would have naturally gained during the course of becoming more and more proficient in using git.

In other words, I do not think you can say that the change will not harm the experts due to both the points 2 (experts can easily make typo) and 3 above (the change breaks the mental model of the world experts would have formed).

Having said all that, it indeed would be useful to selectively revert changes from the work tree files.

Even though you could add good bits interactively, making multiple commits, and remove the remaining debugging cruft at the very end with "git checkout $files" or "git reset --hard", if there are debugging crufts for two or more phases of development, this alternative procedure would not work well, compared to the workflow using Pierre's 'u', which allows you to add necessary bits to commit one phase, remove the debugging bits for that phase (but keeping other debugging bits for the remaining good parts), then continue working and repeat committing and cleaning second and subsequent phases.

It might be enough to change the command key to uppercase "U" to avoid unintended mistakes, and document the fact prominently that this action is an oddball exception to the principle of "git add", while describing why it is an oddball, along the lines of the above discussion, if necessary.