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

From: Dimitar Bonev <dsbonev@gmail.com>
Date: May 4, 2013, 22:46 UTC
Message-ID: <CADeMBopBvCmb4cz8p8vf-jXaOhfzP3GZKF94Efgsh-NOBs+d3Q@mail.gmail.com>
In-Reply-To: <7v61yywm49.fsf@alter.siamese.dyndns.org>

On Sat, May 4, 2013 at 9:48 PM, Jonathan Nieder <jrnieder@gmail.com> 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 <gitster@pobox.com> wrote:

Show 19 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>> 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.