git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] patch-ids.c: cache patch IDs in a notes tree
Date: Mon, 13 May 2013 08:59:07 +0100	[thread overview]
Message-ID: <20130513075906.GP2299@serenity.lan> (raw)
In-Reply-To: <7v1u9bvo1m.fsf@alter.siamese.dyndns.org>

On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> 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.

  reply	other threads:[~2013-05-13  7:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-11 19:54 [PATCH] patch-ids.c: cache patch IDs in a notes tree John Keeping
2013-05-11 21:10 ` Linus Torvalds
2013-05-11 21:49   ` John Keeping
2013-05-11 22:41     ` Linus Torvalds
2013-05-11 23:57       ` Johannes Schindelin
2013-05-12  9:08         ` John Keeping
2013-05-12 11:41           ` [RFC/PATCH v2] patch-ids: " John Keeping
2013-05-12 11:57             ` John Keeping
2013-05-12  3:00       ` [PATCH] patch-ids.c: " Junio C Hamano
2013-05-12  8:59         ` John Keeping
2013-05-12 22:19           ` Junio C Hamano
2013-05-13  7:59             ` John Keeping [this message]
2013-05-13 13:53               ` Junio C Hamano
2013-05-13 14:02                 ` John Keeping
2013-05-13 14:46                   ` Junio C Hamano
2013-05-13 14:59                     ` John Keeping
2013-05-13 15:45                       ` Junio C Hamano
2013-05-13 15:52                         ` John Keeping

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130513075906.GP2299@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).