Re: [PATCH] patch-ids.c: cache patch IDs in a notes tree

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 11, 2013, 22:41 UTC
Message-ID: <CA+55aFzinmXA2HtA3hmN1VVOcLPWedfqJRws0RJMEc1By1VLLg@mail.gmail.com>
In-Reply-To: <20130511214900.GF2299@serenity.lan>

On Sat, May 11, 2013 at 2:49 PM, John Keeping <john@keeping.me.uk> wrote:

Show 6 quoted lines

>
> Hmm... I hadn't realised that.  Looking a bit closer, it looks like
> init_patch_ids sets up its own diffopts so its not affected by the
> command line (except for pathspecs which would be easy to check for).
> Of course that still means it can be affected by settings in the user's
> configuration.

.. and in the actual diff algorithm.

The thing is - patches ARE NOT STABLE. There are many valid ways to get a patch from one version to another, and even without command line changes, we've had different versions of git generating different patches. There are heuristics in xdiff to avoid some nasty "use up tons of CPU-time" things that have been tweaked over time. And even for simple cases there are ambiguous ways to describe the patch.

Now, maybe we don't care, because in practice, most of the time this just doesn't much matter. And anybody who uses patch-ID's had better not rely on them being guaranteed to be unique anyway, so it's more of a "if the patch ID is the same, it's almost guaranteed to be the same patch", but that's a big "almost". And no, it's not some theoretical "SHA1 collisions are very unlikely" kind of thing, it's a "the patch ID actually ignores a lot of data in order to give the same ID even if lins have been added above it, and the patch is at different line numbers etc".

So maybe it doesn't matter. But at the same time, I really think caching patch ID's should be something people should be aware of is fundamentally wrong, even if it might work.

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.

             Linus