Re: [PATCH] Documentation: do not treat reset --keep as a special case
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:26
Jonathan Nieder [off-list ref] writes:
The current treatment of "git reset --keep" emphasizes how it differs from --hard (treatment of local changes) and how it breaks down into plumbing (git read-tree -m -u HEAD <commit> followed by git update-ref HEAD <commit>). This can discourage people from using it, since it might seem to be a complex or niche option. Better to emphasize what the --keep flag is intended for --- moving the index and worktree from one commit to another, like "git checkout" would --- so the reader can make a more informed decision about the appropriate situations in which to use it.
The updated text makes quite a lot of sense ;-) while the old text doesn't. What were we smoking when we wrote it and passed it through the review?
quoted hunk
Signed-off-by: Jonathan Nieder <redacted> Documentation/git-reset.txt | 9 ++------- 1 files changed, 2 insertions(+), 7 deletions(-)diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index fd72976..927ecee 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt@@ -76,15 +76,10 @@ In other words, --merge does something like a 'git read-tree -u -m <commit>', but carries forward unmerged index entries. --keep:: - Resets the index, updates files in the working tree that are - different between <commit> and HEAD, but keeps those - which are different between HEAD and the working tree (i.e. - which have local changes). + Resets index entries and updates files in the working tree that are + different between <commit> and HEAD. If a file that is different between <commit> and HEAD has local changes, reset is aborted.
I saw "updates files" and one question immediately came to mind: update how? "... to match what is in HEAD"? "Resets index entries" is less of a problem as the word "reset" already strongly suggests that the current state does not matter as much as the target state, though. Thanks.