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

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