I think if there was such a command, it could well be common, at least for me. I am somewhat surprised that from the three combinations of resetting index and working dir's states of a file this is the one that is missing (it is missing at commit level also for what is worth). Summary table of resetting commands is present at the end of this article: http://www.progit.org/blog/2011/07/11/reset.html Here is how I see the workflow for a file: you start with a state that matches the HEAD state, you modify the file until reaching the point of a sufficient solution, you mark it as finished work by staging it for the next commit, now that you have a solution you can start over from the HEAD state of the file and try to improve it by choosing a different path of implementation. My initial thought was to checkout the file, but surprisingly this reset the staged state also in addition the working dir's state. Generally git-checkout modifies the working tree, but indeed if you use its form for a single file and specify a treeish argument it will "update the index for the given paths before updating the working tree". I am curious which are the valid use cases for this behavior of git-checkout and if it was the right thing to do to implement it this way. In its current form git-checkout does more work than expected by me: git checkout HEAD -- targetfile The above command should have been implemented to reset the working dir' state of the file only and if one wants to reset its staged state he could use 'git reset HEAD targetfile'. This gives you more flexibility (reset one state, the other state or both states), git-checkout has more consistent behavior (git-checkout a file and git-checkout a branch keeps your staged changes), and makes harder to lose your staged changes (there is a reason for a change to be staged so it should not be so easy to lose it). As the current behavior is released I guess it couldn't not be (or it should not be at all) accommodated to the one described above, so at least another command/option should be added to implement it. @ThomasRast: 'git show HEAD:targetfile > targetfile' was proposed in the both links that I provided in the email that your replied to, but this introduces external dependency to the command interpreter to output the file unmodified but not every interpreter does this. PowerShell in particular modifies the encoding of the file, so I get strange behavior: 'git diff' states that html files are binary ones and it does not show me the differences; 'git apply' prints 'fatal: unrecognized input'. I tried your second suggestion 'git commit' followed by 'git revert', but this reverses the states of all committed files. I prefer something that applies to a single file, like git-checkout and git-reset do. Here is a set of commands more close to what I wish: git commit -m 'a provisional stable solution' git checkout HEAD~1 -- targetfile git commit --amend -am 'add solution to problem x' This requires more commands, makes assumptions about making a commit to a branch, deviates from the rest of git commands about resetting a file's state (inconsistent git API). On Sat, May 4, 2013 at 11:58 AM, Thomas Rast <trast@xxxxxxxxxxx> wrote: > Dimitar Bonev <dsbonev@xxxxxxxxx> writes: > >> I have been looking for such a command/option and no one gave me >> sufficient answer. So this message should be considered as a feature >> request. I had a situation where I had staged a file with a problem >> solution in it, then I wanted to experiment with a different solution >> so I had to revert the file to its HEAD state and I couldn't find a >> way that preserves the staged state of that file. More discussions: >> >> https://groups.google.com/forum/?fromgroups=#!topic/git-users/nYiN-rE_3i0 >> >> http://stackoverflow.com/questions/16335799/git-porcelain-command-to-revert-a-single-file-to-its-head-state-but-keep-its-sta > > Is that a common enough issue to warrant a better solution than > > git show HEAD:targetfile > targetfile > > which is how we would do it? > > Or more likely, > > git commit -m WIP > git revert -n HEAD > > which is safer anyway, since it doesn't lose the formerly-staged state > so easily (you have the reflog in case of any mistakes). > > -- > Thomas Rast > trast@{inf,student}.ethz.ch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html