On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote: > John Keeping <john@xxxxxxxxxxxxx> writes: > > >> But it is not a big problem. Either 3-way merge notices that there > >> is nothing new, or you get a conflict and have chance to inspect > >> what is going on. > > > > It's not a problem here, but false negatives would be annoying if you're > > looking at "git log --cherry-mark". > > The primary thing to notice is that it is not a new problem with or > without the caching layer. As Linus mentioned how patch-ids are > computed by ignoring offsets and whitespaces, the filtering is done > as a crude approximation and false negatives are part of design, so > making the cache more complex by recording hash of the binary and/or > options used to compute misses the fundamental. The caching layer could also introduce false positives though, which is more serious. If you cache patch IDs with a pathspec restriction and then run a command that uses the cache with no such restriction you could hit a patch that is the same for those paths but also touches other paths that you don't want to ignore and mark it as patch identical even though it is not. Adding a hash of the diffopts fixes that. -- 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