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