On Sat, May 11, 2013 at 2:49 PM, John Keeping <john@xxxxxxxxxxxxx> wrote:
>
> 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
--
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