On Sat, May 4, 2013 at 9:48 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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. -- 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