Re: "fatal: git-write-tree: error building trees" from `git stash`

Jeff King [off-list ref] writes:

but I suspect it is not sufficient:

  1. There are other code paths that will end up in write-tree which
     should probably be protected, too.

Among 6 calls to write-tree, only the first ones in create_stash and
apply_stash are about the index the user originally had.  If the
only expected failure case is unmerged entries, it should be
sufficient to protect these two (and the one in apply_stash is
already covered, I think).

  2. Unmerged entries are only one reason that write-tree might fail.
     It's OK not to catch them all (since ultimately write-tree will
     complain if need be), but we may want to also handle intent-to-add
     entries with a nicer message.

Hrmph.

We used to fail write-tree when I-T-A entries existed and relied on
that behaviour to implement "no state lost"; as we broke write-tree
recently by allowing to write a tree out by pretending that I-T-A
entries do not exist, I think we broke it.  Stashing with I-T-A and
then unstashing it may lose the file.  Sigh...