I had done a
git stash
and then
git rebase origin/master
which were both successful.
However
git stash apply
was not so happy:
$git stash apply
Auto-merging yarn/pom.xml
CONFLICT (content): Merge conflict in yarn/pom.xml
Auto-merging unsafe/pom.xml
CONFLICT (content): Merge conflict in unsafe/pom.xml
Auto-merging tools/pom.xml
CONFLICT (content): Merge conflict in tools/pom.xml
Auto-merging streaming/pom.xml
CONFLICT (content): Merge conflict in streaming/pom.xml
Auto-merging sql/hive/pom.xml
CONFLICT (content): Merge conflict in sql/hive/pom.xml
Auto-merging sql/hive-thriftserver/pom.xml
CONFLICT (content): Merge conflict in sql/hive-thriftserver/pom.xml
..
It seems a consensus approach for reverting the apply were:
$git stash show -p | git apply -R
However that results in:
error: patch failed: assembly/pom.xml:20
error: assembly/pom.xml: patch does not apply
error: patch failed: bagel/pom.xml:20
error: bagel/pom.xml: patch does not apply
error: patch failed: core/pom.xml:20
error: core/pom.xml: patch does not apply
error: patch failed: examples/pom.xml:20
error: examples/pom.xml: patch does not apply
error: patch failed: external/flume-assembly/pom.xml:20
.. and so on ..
So then is there any means to roll the whole stash apply back?
Your revert of the stashed changes fails for the same reason that applying the stashed changes did: the underlying content has changed too much, so the patch doesn't quite fit.
If you just want to revert all files to the contents of HEAD, all you need is:
git reset --hard
From the manual:
git reset [<mode>] [<commit>]
This form resets the current branch head to <commit> and possibly
updates the index (resetting it to the tree of <commit>) and the
working tree depending on <mode>. If <mode> is omitted, defaults to
"--mixed". The <mode> must be one of the following:
--hard
Resets the index and working tree. Any changes to tracked files
in the working tree since <commit> are discarded.