[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH] git-add -p: be able to undo a given hunk
From:       Jeff King <peff () peff ! net>
Date:       2009-07-24 17:06:22
Message-ID: 20090724170622.GA20247 () sigill ! intra ! peff ! net
[Download RAW message or body]

On Fri, Jul 24, 2009 at 09:06:16AM -0700, Junio C Hamano wrote:

> 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.

Perhaps it makes sense to have an interactive stash rather than an
interactive revert? Then the reverts that you make are still being saved
somewhere, and you can recover from an error by applying the stash. Not
to mention that interactive stash is useful in its own right.

The downside is that if you are the sort of person who keeps a clean
stash list (and I am not such a person), then you have this
"to-be-deleted" cruft on the top of your stash (whereas with a true
revert, it just goes away).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]