This is totally unrelated to this thread, but I am seeing a strange error from the "let's make sure we won't write null sha1" code we added recently. This reproduces reliably for me, even in a freshly cloned repository without previous rerere records:
- Check out v1.8.4.1 $ git checkout v1.8.4.1^0 at this point your HEAD should be detached. - Apply the first patch from this series $ git am -3 20131031063530.ga5...@sigill.intra.peff.net - Apply the second patch from this series $ git am -3 20131031063626.gb5...@sigill.intra.peff.net Up to this point things should advance smoothly - Attempt to apply the second patch _again_. $ git am -3 20131031063626.gb5...@sigill.intra.peff.net This should detect a no-op, but somehow leaves things in a conflicted state. I haven't looked into what is wrong, but this message is not about this failure. - Try to discard $ git am --abort error: cache entry has null sha1: remote-curl.c fatal: unable to write new index file This should not happen, no? "git reset --hard" will remove the funnies, but still... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
