Jonathan del Strother <maillist@xxxxxxxxxxxxxx> writes:
> $ git stash list
> stash@{0}: On master: --apply
> stash@{1}: WIP on master: 09e3c30... Better handling of cell sizes in
> the grid
>
> $ git stash show stash@{1}
> ...
> 19 files changed, 0 insertions(+), 3805 deletions(-)
>
> Hmm. Looks like it's trying to delete all of my versioned files.
> "git stash apply stash@{1}" confirms this. Obviously that's not what
> I tried to stash - my WIP when I stashed was a few additions, a couple
> of new unversioned files, and moving a few lines of code from one file
> to another.
>
> Any ideas what happened there? I can't seem to reproduce the problem
> in a test repository.
There are two possibilities that I can think of offhand, neither
of them is about git-stash but about the state you ran stash
from.
Whenever anybody wonders where inadvertent reverting changes
come from, two most likely reasons are incorrect push into the
current branch's tip initiated from elsewhere, or incorrect
fetch into the current branch's tip initiated from the
repository.
If your work repository is foo, and if you are working on
'master' branch, you could
$ cd ../bar ; git push ../foo master:master
to push from elsewhere to update the tip of the checked out
branch. This makes the index and the work tree that was based
on the old commit in foo repository totally out of sync with
respect to the HEAD (which you are replacing), and committing
that state would revert the change the above push made.
You can do the same by doing something equally silly and
destructive by:
$ git fetch --update-head-ok ../bar master:master
After these operations that could make your index and work
tree state to include reverts, if you "stash", the stash will
record that the reverting was what you wanted to do.
I am not saying this is the only possible explanation though.
You can try:
git ls-tree stash@{1}
git rev-parse stash@{1}^1
git diff stash@{1}^1 stash@{1}^2
The stash entry itself is the state of the work tree, its first
parent (i.e. ^1) is the commit your stash was originally based
on, and its second parent (i.e. ^2) is what was recorded in the
index. Is the output from the first one empty? Does the second
command show you that you were on the commit you thought you were
on? Does the third command show you what you thought you have
told "git add" to put in the index just before you made the
stash?
-
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
