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

On Sat, May 4, 2013 at 9:48 PM, Jonathan Nieder [off-list ref] wrote:

Is there no way to convince PowerShell to treat the output of a
command as binary data with no particular encoding?

The best I could find out is to pipe the output to set-content:

git show HEAD:targetfile | set-content targetfile

The default console output redirection pipes the output to Out-File
which encodes the resulting file by default with little endian unicode
encoding, but it can be overridden by providing an argument:

git show HEAD:targetfile | Out-File -encoding utf8 targetfile

Also if I provide 'default' encoding to Out-File it produces the exact
same result as set-content command:

git show HEAD:targetfile | Out-File -encoding default targetfile

The API docs state that "Default" uses the encoding of the system's
current ANSI code page. So I guess it is system dependent, it could be
the case for set-content also, but at the very least set-content is
shorter to write.

On Sat, May 4, 2013 at 11:01 PM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

But if your result is _also_ something worth saving, what would you
do?  "git add" to update the index will trash the work that was in
the index, and that is by definition unrelated to what you worked on
in the working tree (you wanted to start from the version in the
HEAD, not from the version in the index, so the end result is likely
to lack the work you saved in the index).

As Thomas said, I think a more reasonable workflow would begin by
saving the "somewhat worth saving" state you have in your index as a
WIP commit, i.e.

      git commit -m wip

When I experiment starting from a clean slate (after saving away
such a WIP commit), I would then do this:

        git checkout HEAD^

Actually this is not the case as I tried to explain with the 'git
commit' followed by 'git checkout HEAD~1 -- targetfile' followed by
'git commit --amend' example. The index and the working dir states are
very well related. Lets imagine that I am adding an MVC feature X - it
could be implemented with 3 or more files. If I stage the files and
came up with an idea that requires a major rewrite of one of these
files - lets say the controller one - then it is more convenient to
checkout the file's HEAD state and build on top of it - I had been
doing just that right before staging - building the previous
implementation so this is so familiar and still recent in time. If the
new controller implementation is less acceptable than the old one I
just commit, otherwise I stage the new implementation and just commit.
So simple, so common workflow.

One more argument against the suggestion of doing a commit ahead of
time is that I like to think in separation to reduce complexity - in
particular I like to think only for the working dir and index states,
commits - I treat them as finished work. If I have to amend a commit,
it is about fixing a mistake - adding/removing a wrong file, fixing a
typo, that sort of things and not for actual work to be done.