Thomas Rast <trast@xxxxxxxxxxx> 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.
--
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