Re: Darcs and git: plan of action

From: Ray Lee <ray-lk@madrabbit.org>
Date: Apr 19, 2005, 23:21 UTC
Message-ID: <1113952916.29444.60.camel@orca.madrabbit.org>
In-Reply-To: <42658D95.7020404@tupshin.com>

On Tue, 2005-04-19 at 16:00 -0700, Tupshin Harper wrote:

Show 9 quoted lines

> 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 different system.

Show 13 quoted lines

> A more fundamental problem comes back to intent. If I have a file
> "foo" before:
> a1
> a2
> and after:
> b1
> b2
> is that a "replace [_a-zA-Z0-9] a b foo" patch, or is that a
> -a1
> -a2
> +b1
> +b2
> patch?

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.

Ray