Ray Lee wrote:

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.

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.

And since the
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.)

See above for one set of limitations on this. A more fundamental problem comes back to intent. If I have a file "foo" before:
and after:
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.

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

Reply via email to