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

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

[Dimitar Bonev]

Hi,

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

Regards,
Dimitar Bonev

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

[Thomas Rast]

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

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

[Dimitar Bonev]

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

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

[Jonathan Nieder]

Dimitar Bonev wrote:

> @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

That would suggest that "git show" (along with similar commands like
"git diff") should learn an --output= option to avoid its output being
corrupted.  It doesn't leave me very happy.

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

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

[Junio C Hamano]

Thomas Rast <trast@inf.ethz.ch> 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.
> ...

"I have something worth saving, better than HEAD in some way
(e.g. contains fixes), in my index. I want to keep it while I
experiment an approach that is unrelated to it, so I want a clean
slate in the working tree from HEAD without disturbing the index".

At the first glance, that looks like a reasonable thing to ask, but
after thinking about it a bit more, I am not sure if it really is,
primarily because it is unclear what you can productively do to the
end result next.

Suppose you matched the working tree to HEAD while keeping a
valuable change in the index, and after working for a while, now
have finished the experiment and have something in your working
tree.

What is your next move?

If the end result in the working tree were "Nah, this other approach
does not work, trash it", you can checkout the working tree from the
index, so nothing is lost.

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).

That makes me think that "match working tree from HEAD bypassing
index" is not a very useful strategy, unless you are expecting a
failed experiment from the start.

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^

to start at the state before the WIP commit and hack away.  As I do
not know how the experiment would go when I do this, I often do not
bother giving the experiment its own branch.

If the experiment does not seem to go in a productive direction, I
can simply "git reset --hard && git checkout -" to get rid of it.

On the other hand, if its direction shows promise but turns out to
be more involved than a quick hack, I can at that point decide to
give it its own branch with "git checkout -b newbranch".  Then I can
choose to keep working on it, or switch to other tasks after making
a wip commit on that new branch.

Or if the experiment results in a series of good and straightforward
changes that should come _before_ that original wip (which happens
very often), then I could do:

	git commit ;# maybe more commits.
        git cherry-pick @{-1} ;# the one stashed away
        git co -B @{-1}

to update the original branch and come back to it.  The state in the
original index may be a WIP, so I may then reset with

	git reset HEAD^

after the above.

> 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 "git diff HEAD <paths> | git apply -R", which is a good trick to
learn.  You can inspect "git diff HEAD <paths>" to check what you
will lose and then add "| git apply -R" to actually revert it.

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> "I have something worth saving, better than HEAD in some way
> (e.g. contains fixes), in my index. I want to keep it while I
> experiment an approach that is unrelated to it, so I want a clean
> slate in the working tree from HEAD without disturbing the index".
>
> At the first glance, that looks like a reasonable thing to ask, but
> after thinking about it a bit more, I am not sure if it really is,
> primarily because it is unclear what you can productively do to the
> end result next.
>
> Suppose you matched the working tree to HEAD while keeping a
> valuable change in the index, and after working for a while, now
> have finished the experiment and have something in your working
> tree.
>
> What is your next move?
>
> If the end result in the working tree were "Nah, this other approach
> does not work, trash it", you can checkout the working tree from the
> index, so nothing is lost.
>
> 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).
>
> That makes me think that "match working tree from HEAD bypassing
> index" is not a very useful strategy, unless you are expecting a
> failed experiment from the start.
>
> 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^
>
> to start at the state before the WIP commit and hack away.  As I do
> not know how the experiment would go when I do this, I often do not
> bother giving the experiment its own branch.
>
> If the experiment does not seem to go in a productive direction, I
> can simply "git reset --hard && git checkout -" to get rid of it.
>
> On the other hand, if its direction shows promise but turns out to
> be more involved than a quick hack, I can at that point decide to
> give it its own branch with "git checkout -b newbranch".  Then I can
> choose to keep working on it, or switch to other tasks after making
> a wip commit on that new branch.
>
> Or if the experiment results in a series of good and straightforward
> changes that should come _before_ that original wip (which happens
> very often), then I could do:
>
> 	git commit ;# maybe more commits.
>       git cherry-pick @{-1} ;# the one stashed away
>       git co -B @{-1}
>
> to update the original branch and come back to it.

Also, if the alternative experiment was really to replace what you
originally did to your index, as a natural extension to the above
workflow, you would omit "cherry-pick" step in the above.  Your
perfected alternative solution will become the true history of the
original branch, discarding the tentative solution in the index.

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

[Dimitar Bonev]

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:
> 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.

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

[Thomas Rast]

Dimitar Bonev <dsbonev@gmail.com> writes:

> 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.

Aside from what's been said already, there's a fundamental problem with
your approach: it doesn't scale in any direction.  You cannot use it if
you want to do the same dance with more than one version "set aside",
because the index gives you exactly one more storage area.  And it does
not generalize in any useful way, whereas using temporary commits is
useful also if you want to briefly leave a branch with unfinished work
to do something else.  Furthermore, knowing how to work with temporary
commits (in the plural), and clean them up using 'rebase -i', *is* a
part of "work to be done" in most git workflows.  Namely, it is used to
reshape your branch from a "how did I hack this up" angle into a "how do
I explain this to others" angle.

So I hope I'm not misconstruing what Junio and Jonathan said, but I
think you can sum up our position as: your proposal is a very specific
solution to a very narrow problem -- that is only needed because your
environment (PowerShell) is arguably broken.  All the while, there are
several existing solutions that we consider more natural, and that
generalize to other use-cases.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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

[Junio C Hamano]

Dimitar Bonev <dsbonev@gmail.com> writes:

[administrivia: please do not drop people out of Cc list]

> 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.

That invites another question: if it is very well related, why isn't
it an option to start from the state you have in the working tree
(i.e. doing nothing), or in the index (i.e. "git checkout
controller")?

But the answer does not matter that much in the end.

> 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

So you have satisfactory changes for view and model in the index,
and changes to the controller that maybe is OK but you think it
could be improved, and you want to go back to the clean slate to
rethink the approach only for the controller part?

I think the story is essentially the same.  Let's say you did

    git diff HEAD controller | git apply -R
    edit controller

to get rid of the changes in the working tree, further worked on the
controller part, and came up with a different implementation.  Then
you would presumably do

    git add controller

but at that point you would lose the "maybe OK" version you had in
the index.  What if you think the version in the working tree might
end up being better than "maybe OK" but can still be improved
further?  You never "git add" until the working tree version gets
into truly a better shape?

What happens fairly often is that you end up having more than _one_
versions that are both better than the version from the HEAD but
cannot immediately say one is clearly better than the others in all
counts, and at some point, you would need more than one intermediate
states (while the index can have only one), to keep these competing
versions. The next thing you would want to do is to take a deep
breath and pick better parts from these good versions to come up
with the single final version. Keeping one good version in the index
does not let you do so.

> ... commits - I treat them as finished work.

I think people should learn to take the biggest advantage of using a
distributed source control system, which is that commits do not have
to be "finished work", until you choose to declare they are done and
push them out for others to see.

Fear of commitment is a disease we do not have to suffer once we
graduated centralized systems ;-).

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

[Dimitar Bonev]

Junio C Hamano <gitster@pobox.com> wrote:
> Dimitar Bonev <dsbonev@gmail.com> writes:
>
> [administrivia: please do not drop people out of Cc list]
>
> That invites another question: if it is very well related, why isn't
> it an option to start from the state you have in the working tree
> (i.e. doing nothing), or in the index (i.e. "git checkout
> controller")?
>
> But the answer does not matter that much in the end.
>

It isn't an option to start from the staged state, because the staged
implementation modified code that is present in the HEAD state. So the
new implementation that I have in my mind requires to add its own kind
of modifications which are incompatible with the staged
implementation. It is much easier to start from HEAD state when both
implementations require modifying 10% HEAD code and adding 90% new
code. If I start from staged state I have to drop 90% new code and to
figure out if the 10% modified state can work without the 90% dropped
code. At the same time I know HEAD state is stable working code. There
is no doubt that I have to start from HEAD state of the controller
file for the described MVC example

>
> I think the story is essentially the same.  Let's say you did
>
>     git diff HEAD controller | git apply -R
>     edit controller
>
> to get rid of the changes in the working tree, further worked on the
> controller part, and came up with a different implementation.  Then
> you would presumably do
>
>     git add controller
>
> but at that point you would lose the "maybe OK" version you had in
> the index.  What if you think the version in the working tree might
> end up being better than "maybe OK" but can still be improved
> further?  You never "git add" until the working tree version gets
> into truly a better shape?
>

Yes, I 'git add' only what is to become part of the next commit so at
least it has to be stable code (that passes some smoke tests or
something similar).

> What happens fairly often is that you end up having more than _one_
> versions that are both better than the version from the HEAD but
> cannot immediately say one is clearly better than the others in all
> counts, and at some point, you would need more than one intermediate
> states (while the index can have only one), to keep these competing
> versions. The next thing you would want to do is to take a deep
> breath and pick better parts from these good versions to come up
> with the single final version. Keeping one good version in the index
> does not let you do so.
>

My case was not like that but if it was I would have made a commit to
preserve the old implementation while working on the new one.

>
> I think people should learn to take the biggest advantage of using a
> distributed source control system, which is that commits do not have
> to be "finished work", until you choose to declare they are done and
> push them out for others to see.
>
> Fear of commitment is a disease we do not have to suffer once we
> graduated centralized systems ;-).

I used the wrong words - I meant 'stable state' instead of 'finished
work'. If every commit was finished work then all my branches would
have contain one specific commit. My branches are built from more than
one commit and every commit adds a subfeature and the commit should be
stable in sense that it should run without throwing exceptions - like
trying to load some file that would be created in a future commit. One
should be able to checkout a random commit and be able to run,
inspect, write tests against, add new subfeature on top of that
commit.