Jeff King <peff@xxxxxxxx> 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... -- 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