Hi John & Linus, On Sat, 11 May 2013, Linus Torvalds wrote: > [...] I really think caching patch ID's should be something people > should be aware of is fundamentally wrong, even if it might work. Given the incredible performance win, I would say it is still worth looking into. If you store also a hash of Git version and diff options (may even be the hash of the raw bytes of the diff options if you do not plan to share the ref between machines) with the patch ID, you can make it safe. That hash would be generated at patch_id init time and load_cached_patch_id() would check this hash in addition to the return value of get_sha1() (and ignore the note if the version/diff options differ). If you are following git.git slavishly, maybe hashing just the major/minor Git version would be in order to avoid frequent regeneration of identical patch IDs. > And quite frankly, if you do rebases etc so much that you think patch > ID's are so important that they need to be cached, you may be doing > odd/wrong things. AFAICT John actually gave a very valid scenario that validates his use case: git-gui patches are best tested in the git.git scenario but have to be contributed via git-gui.git. It's not John's fault that this typically requires a lot of rebasing between vastly divergent histories. John, do you think you can incorporate that "finger-print" of the patch ID generation and store it in the same note? Ciao, Johannes -- 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