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

Thomas Rast <trast@inf.ethz.ch> 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. The state in the original index may be a WIP, so I may then reset with

	git reset HEAD^

after the above.

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.