Re: Using Origin hashes to improve rebase behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 11, 2011, 19:32 UTC
Message-ID: <7v4o8a1i6k.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110211190326.GB29203@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Exactly. One other possible solution to this problem would be to somehow
> make patch-ids handle fuzzy situations better. I doubt it is possible to
> do that without introducing a lot of false positives, though.

We need to remember that we would want to tolerate _no_ false positive.

We try hard to err on the safer side and leave the hard case to the users for a reason. A tool that records correct results 99.9% of the time but produces wrong results for the rest of the time _silently_ is a tool that cannot be trusted, and forces the user to inspect its output carefully to make sure it is correct, not just for the 0.1% cases but for all of them.

Among the many automation support facilities we have gained over time, the three-way merge, recursive merge to come up with a synthetic merge base tree, detecting change similarity with patch-id, and detecting renames by content inspection all proved themselves to be reasonably trustworthy without false positives, even though they sometimes fail with false negatives and they do so rather loudly by failing. I find the heuristics in rerere is trustable most of the time but I still do not completely trust it myself.

Patching with fuzz and a user declaration that "this change came from that", especially if the user can declare the correspondence even when conflict resolution is involved during the porting of changes from totally different context, fall into a different, a lot less trustworthy, basket. It needs to start from totally trivial cases and punt _loudly_ when there is any doubt.