John Keeping [off-list ref] writes:
quoted
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.
On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
quoted
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.