Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > git-reset could be used in three different ways: > > - move HEAD to somewhere, optionally (not) update worktree/index > - "move" HEAD to HEAD, mainly to update worktree/index > - just update the index from some tree-ish > > The second case is frankly a (neat) corner case of the first one. But it > makes it impossible for me to summarize git-reset in one line. Without > it at least I could write "reset HEAD or the index". > > And even "reset all the things" is not correct because reseting worktree > selectively is the job of git-checkout, not git-reset. Sigh. I am not so sure if the current one is too bad. The primary action of the command is to reset the current HEAD to point at a specified commit, and everything else it does is to make things consistent (in other words, in line with having the HEAD at the given commit) with respect to different requirements. The "soft" reset wants to keep the index and the working tree intact, the "merge" reset wants to undo what a mergy operation would have done to the index and the working tree if it started from a clean state, etc. And "reset the HEAD" is quite approiprate for a single line summary of what the command does. It perfectly is fine as long as the differences brought in by having various "modes" are sufficiently described, I would think. > diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt > index 26e746c53f..e12d8edee6 100644 > --- a/Documentation/git-reset.txt > +++ b/Documentation/git-reset.txt > @@ -3,7 +3,7 @@ git-reset(1) > > NAME > ---- > -git-reset - Reset current HEAD to the specified state > +git-reset - Reset "something" > > SYNOPSIS > --------
