@Rodrigo gave a correct way to list the different blobs (:{1,2,3}:file), here is some more context on how git stash works :
git stash actually does create a commit, and stores this commit in a reference named refs/stash.
You can view this by inspecting this ref's history :
$ git log --oneline --graph stash
# or equivalently :
$ git log --oneline --graph stash@{0}
* f8ac2b6 (refs/stash) WIP on sidetrack: e330a4e edited on sidetrack
|\
| * e20e1a8 index on sidetrack: e330a4e edited on sidetrack
|/
* e330a4e (HEAD -> sidetrack) edited on sidetrack
* 78db1ef add thefile.txt
...
(side note : if you have several stashes, they are actually listed in the reflog of this refs/stash reference : git reflog stash, and you can access older versions of a ref using stash@{1}, stash@{2}, etc ... )
Applying a stash is roughly equivalent to running git cherry-pick stash.
So, if you have a conflict on file that/file.txt when running git stash pop or git stash apply, you will find :
ours version in HEAD (as usual) : git show HEAD:that/file.txt
theirs version in stash or stash@{0} : git show stash:that/file.txt
base version in the parent of stash : git show stash^:that/file.txt
As you can see above the stash is actually a merge commit, it stores the worktree version of the files (refs/stash), and the indexed version of the files (its second parent refs/stash^2), which can be different if you had anything added and not committed yet.
If you apply git stash apply --index or git stash pop --index (and git stash tries to restore the content of the index), you have to look closer at what step triggered the conflict : restoring the worktree or the index.