On Tue, 2005-04-19 at 16:00 -0700, Tupshin Harper wrote:
> 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.
I had a precondition on my argument (not quoted), that the code was
checkpointed before and after. Obviously, a large set of changes in one
patch is a problem. However, a darcs replace is (effectively) a commit
on its own, so I was limiting myself to the same situation under a
> 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
Okay, so in reading the online darcs manual (yet) again, I now see that
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.)
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?
> 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.
Unless I'm missing something, the darcs replace patch can already do the
wrong thing. 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?
> It's provable that you can not.
I'm still not seeing the problem, at least when it comes to ANSI C.
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