On 12-08-15 02:46 PM, Junio C Hamano wrote:
Junio C Hamano <gits...@pobox.com> writes:

Thomas Rast <tr...@student.ethz.ch> writes:

This has come up before, and actually led to the introduction of
'checkout -p' and 'reset -p':

That is a blast from the past.

Why is saying "git checkout ." too much work, after "add -p" that
you excluded the debugging cruft?
Please forget this question.  A better way in the form of "stash -p"
was suggested in the old thread to get rid of debug cruft in the
tree before an "add -p" session (or during a series of "add -p"

So is this still an issue?

I read most of the thread, and I do think it still is. Here are my 2 cents:

1. The alternative commands aren't nearly as time efficient:
- git checkout . is fast and awesome, but you can't use it if, for example, you have to maintain a dirty working tree - git (stash|reset|checkout) -p make you go through (all|most) of the hunks you have to hunt down those 2 lines that say "echo 'This line is runningantoeuhaoeuaoae'"

2. All of the safety concerns can be alleviated with the right interface. I am glad the u option mentioned in the thread did not go through since I agree it is not ideal. However, if the command is:
    (a) something with a '!', then no one will hit it by mistake, and
    (b) the prompt makes it clear that work is lost
then I think it would be fine

The advantages of a command like this are pretty huge IMO. I can see this being a big time saver.

How about adding this to the git add -p prompt:

r! - remove this hunk. The hunk is discarded from the working tree, and is irrevocably lost.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to