Often I find it useful to selectively undo the modifications that I
did to my working tree. The -p option to 'reset' that selectively
resets changes back to a given commit. Unfortunately the option
reports itself to be incompatible with --{hard,soft,mixed} and thus
can't be applied to working tree.
Right now I do this with vimdiff, by applying 'git diff' in reverse.
Wish reset supports -p on working tree operations as well because the
-p framework (of add, and reset) feels good to use.
--
Jeenu
On Tue, Nov 23, 2010 at 10:11 AM, Jeenu V [off-list ref] wrote:
Often I find it useful to selectively undo the modifications that I
did to my working tree. The -p option to 'reset' that selectively
resets changes back to a given commit. Unfortunately the option
reports itself to be incompatible with --{hard,soft,mixed} and thus
can't be applied to working tree.
Right now I do this with vimdiff, by applying 'git diff' in reverse.
Wish reset supports -p on working tree operations as well because the
-p framework (of add, and reset) feels good to use.
there's `git checkout -p` to selectively remove changes from your working tree.
(also `git stash -p` to selectively stash changes temporarily)
`git reset -p` will only undo staged changes from your index
--
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
On Tue, Nov 23, 2010 at 2:50 PM, knittl [off-list ref] wrote:
On Tue, Nov 23, 2010 at 10:11 AM, Jeenu V [off-list ref] wrote:
quoted
Often I find it useful to selectively undo the modifications that I
did to my working tree. The -p option to 'reset' that selectively
resets changes back to a given commit. Unfortunately the option
reports itself to be incompatible with --{hard,soft,mixed} and thus
can't be applied to working tree.
Right now I do this with vimdiff, by applying 'git diff' in reverse.
Wish reset supports -p on working tree operations as well because the
-p framework (of add, and reset) feels good to use.
there's `git checkout -p` to selectively remove changes from your working tree.
(also `git stash -p` to selectively stash changes temporarily)
Surprised to know that checkout and stash supports it! Thanks a lot
for pointing out.
--
Jeenu
On Tue, Nov 23, 2010 at 3:56 PM, Jeenu V [off-list ref] wrote:
On Tue, Nov 23, 2010 at 2:50 PM, knittl [off-list ref] wrote:
quoted
quoted
Right now I do this with vimdiff, by applying 'git diff' in reverse.
Wish reset supports -p on working tree operations as well because the
-p framework (of add, and reset) feels good to use.
there's `git checkout -p` to selectively remove changes from your working tree.
(also `git stash -p` to selectively stash changes temporarily)
Surprised to know that checkout and stash supports it! Thanks a lot
for pointing out.
I think Git could suggest 'checkout -p' and/or 'stash -p' when user
tries to use -p with --{hard,soft,mixed} with reset command (in
addition to mentioning that they're incompatible), since relatively
new users are used to 'reset' than other commands to reset their
working trees.
--
Jeenu
On Tue, Nov 23, 2010 at 11:32 AM, Jeenu V [off-list ref] wrote:
On Tue, Nov 23, 2010 at 3:56 PM, Jeenu V [off-list ref] wrote:
quoted
On Tue, Nov 23, 2010 at 2:50 PM, knittl [off-list ref] wrote:
quoted
quoted
Right now I do this with vimdiff, by applying 'git diff' in reverse.
Wish reset supports -p on working tree operations as well because the
-p framework (of add, and reset) feels good to use.
there's `git checkout -p` to selectively remove changes from your working tree.
(also `git stash -p` to selectively stash changes temporarily)
Surprised to know that checkout and stash supports it! Thanks a lot
for pointing out.
I think Git could suggest 'checkout -p' and/or 'stash -p' when user
tries to use -p with --{hard,soft,mixed} with reset command (in
addition to mentioning that they're incompatible), since relatively
new users are used to 'reset' than other commands to reset their
working trees.
`git reset` seldomly affects the working tree, unless using `--hard`,
`--merge` or `--keep`, and those switches are potentially dangerous if
you are not aware of the implications to your worktree and index.
without options reset undoes a previous add, i.e. remove changes from
the index, but not the working tree.
git reset manpage mentions git-checkout:
After running git reset <paths> to update the index entry, you can
use git-checkout(1) to check the contents out of the index to the
working tree. Alternatively, using git-checkout(1) and specifying a
commit, you can copy the contents of a path out of a commit to the
index and to the working tree in one go.
On Tue, Nov 23, 2010 at 4:28 PM, knittl [off-list ref] wrote:
`git reset` seldomly affects the working tree, unless using `--hard`,
`--merge` or `--keep`, and those switches are potentially dangerous if
you are not aware of the implications to your worktree and index.
without options reset undoes a previous add, i.e. remove changes from
the index, but not the working tree.
git reset manpage mentions git-checkout:
Agreed. What I'm saying is most manuals/guides out there tips user to
use 'git reset --hard' to discard changes in the working directory and
restore the pristine copy of files. 'reset' then becomes synonymous to
discard, and it kind of is but for a different reason. Because other
commands offer -p for selective operations, one might try to discard
selectively, and end up using 'git reset -p --hard', which obviously
isn't going to work.
Knowing the users intention in such cases, I was suggesting the error
message could hint the right command (just like git commit hints user
to use git-add when one does 'git commit' with a dirty working tree).
But that's just me.
--
Jeenu