Ray Lee wrote:
This is assuming that you only have one replace and no other operations recorded in the patch. If you have multiple replaces or a replace and a traditional diff recorded in the same patch, then this is not true.Here's where we disagree. If you checkpoint your tree before the replace, and immediately after, the only differences in the source-controlled files would be due to the replace.
And since theSee above for one set of limitations on this. A more fundamental problem comes back to intent. If I have a file "foo" before:
language of the file is known (and thereby the tokenization -- it *is*
well-defined), then a tokenizer that compares the before and after trees
(for just the files that changed, obviously), can discover what you did,
and promote the mere ASCII diff into a token-replace diff. (The same
sort of idea could be done for reindention, I'd hope.)
is that a "replace [_a-zA-Z0-9] a b foo" patch, or is that a
patch? Note that this comes down to heuristics, and no matter what you use, you will be wrong sometimes, *and* the choice that is made can substantively affect the contents of the repository after additional patches are applied.
We agree on everything except that it's provable that one can discover a
replace operation, given a before and after tree.
It's provable that you can not.
-Tupshin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html