On Wed, Dec 20, 2017 at 11:36 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Tue, Dec 19, 2017 at 4:01 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Stefan Beller wrote: >>> On Tue, Dec 19, 2017 at 2:44 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> >>>> checkout -f >>>> I think I would expect this not to touch a submodule that >>>> hasn't changed, since that would be consistent with its >>>> behavior on files that haven't changed. >> [...] >>> I may have a different understanding of git commands than you do, >>> but a plain "checkout -f" with no further arguments is the same as >>> a hard reset IMHO, and could be used interchangeably? >> >> A kind person pointed out privately that you were talking about >> "git checkout -f" with no further arguments, not "git checkout -f >> <commit>". In that context, the competing meanings I mentioned in >> https://crbug.com/git/5 don't exist: either a given entry in the >> worktree matches the index or it doesn't. >> >> So plain "git checkout -f" is similar to plain "git reset --hard" >> in that it means "make the worktree (and index, in the reset case) >> look just like this". > > with "this" == the argument that was given, if the argument > was omitted, HEAD is assumed. > >> checkout -f makes the worktree look like the index; > > No, here is what my installation of git (recent master) does: Well, you are technically correct, the worktree is made look like the index, but prior to that the index is reset to the HEAD, so for me it is easier to understand as "make worktree and index like HEAD"
