Re: Add porcelain command to revert a single staged file to its HEAD state while preserving its staged state

[Dimitar Bonev <dsbonev@gmail.com>]

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@inf.ethz.ch> wrote:
> Dimitar Bonev <dsbonev@gmail.com> 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