Ray Lee wrote:
it allows regular expressions for the match and replace, which means
multiple unique tokens could change atomically. (Does anyone actually
*use* regexes? Sounds like a cannon that'd be hard to aim.)
Yes, and replace patches need to be used very carefully.
Regardless, I only care about code, not free text. If it's in a language
that doesn't do some use-'em-as-you-need-'em duck typing spiel
(<cough>python</cough), then the context of your patch (namely, the
file) already has those tokens somewhere in them. And I bet that if
*you* looked at that file, you could tell if it was a replace or a mere
textual diff. Am I wrong?
Yes. See my hello world example from my last email.
Unless I'm missing something, the darcs replace patch can already do the
wrong thing.
Yes, depending on how you define wrong. Darcs replace is fully
predictable, and poorly chosen replaces can lead to incorrect results
after future patches are applied.
If I do a replace patch on a variable introduced in a local
tree, then do a darcs replace on it before committing it to a shared
repository, and coder B introduces a variable of the same original name
in my copy, then there's a chance that the replace patch will
incorrectly apply upon his newly introduced variable. No?
Absolutely correct, and the exact reason why replace patches need to be
used *very* selectively.
It's provable that you can not.
I'm still not seeing the problem, at least when it comes to ANSI C.
Ray
See hello world example in my other email. You can argue that it is an
existing problem in darcs, but really, it just points out the fact that
a computer is *incapable* of knowing whether it is safe to use a replace
patch based on a diff because replace patches are dangerous if not used
intelligently.
-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
