Jeff King <peff@xxxxxxxx> writes: > As I mentioned earlier, I wanted this to be generic and size-agnostic, > because I'd also like to try caching patch-ids for git-cherry. Sounds like a good thing to aim for, but "Object Cache" sounded too much like giving access to the object data that is faster than either loose or packed objects. This is a completely unrelated tangent but because you brought up patch-ids ;-), the other day I tried to rebase mm patches on top of updated linux-next while trying to help Andrew, and noticed that in real life, many "duplicate" patches you find in updated upstream are "slightly reworded better" and "rebase --skip" is often the right thing to do, but it is often very difficult to diagnose, as (1) the patch you are trying to apply from your old series may be part of a long patch series, and (2) the commit you are trying to re-apply the said patch to, i.e. the updated upstream, may already contain many of these semi-duplicate patches. The conflict resulting from "am -3" in such a situation is not very pleasant to look at (it looks mostly as if you are reverting the effect of updated versions of later patches in your series). -- 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