Re: [darcs-devel] Darcs and git: plan of action

[Kevin Smith <yarcs@qualitycode.com>]

Ray Lee wrote:
> On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
> 
>>>>The other is "replace very instace of identifier `foo` with identifier`bar`".
>>>
>>>That could be derived, however, by a particularly smart parser [1].
>>
>>No, it can't. Seriously. A darcs replace patch is encoded as rules, not
>>effects, and it is impossible to derive the rules just by looking at the
>>results. Not difficult. Impossible.
> 
> 
> Okay, either I'm a sight stupider than I thought, or I'm not
> communicating well. Same net effect either way, I 'spose.
> 
> If I do a token replace in an editor (say one of those fancy new-fangled
> refactoring thangs, or good ol' vi), a token-level comparator can
> discover what I did. That link I sent is an example of one such beast.

The big feature of a darcs replace patch is that it works forward and
backward in time. Let me try to come up with an example that can help
explain it. Hopefully I'll get it right. Let's start with a file like
this that exists in a project for which both you and I have darcs repos:

cat
dog
fish

Now, you change it to:

cat dog
dog
fish

while I simultaneously do a replace of "dog" with "plant", resulting in:

cat
plant
fish

We merge. The final result in both of our trees is:

cat plant
plant
fish

Notice that just by looking at my diffs, you can't tell that I used a
replace operation. I didn't just replace the instances of "dog" that
were in my file at that moment. I conceptually replaced all instances,
including ones that aren't there yet.

Now, I should mention here that I personally dislike the replace
operation, and I think it is more dangerous than helpful. However, other
darcs users are quite happy with it, and it certainly is a creative and
powerful feature.

Other creative patch types have also been dreamed of. For example, a
powerful language-specific refactoring operation has been discussed as a
far-future possibility. That would be safe, and cool.

>>Automated refactoring tools, for example, perform the
>>rename+modify as an atomic operation.
> 
> And that's harder, I agree. But unless I'm missing some nifty
> refactoring editor out there that integrates with darcs during the edit
> session, the user *still* has to tell the SCM about the rename manually.

Although there are no such nifty refactoring tools available today, they
will exist at some point. If they existed today, the world would be a
better place.

Even without tools, many shops have policies against checking in code
that won't compile. If you rename a java class, you must simultaneously
perform the rename and modify the class name inside. If you commit
between those steps, it's broken. [I do realize that the kernel doesn't
have java code, by the way.]

I should also mention that I currently believe that Linus is correct
that explicit rename tracking is not required for git. I have every hope
that his plan for handling the more general case of "moved text" will
take care of renames as a side effect. I don't know if that will be
sufficient to allow a two-way lossless gateway between git and darcs or
other systems that do track renames explicitly.

Kevin