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

From: Kevin Smith <yarcs@qualitycode.com>
Date: Apr 19, 2005, 02:05 UTC
Message-ID: <4264677A.9090003@qualitycode.com>
In-Reply-To: <1113874931.23938.111.camel@orca.madrabbit.org>

Ray Lee wrote:

Show 17 quoted lines

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

Show 6 quoted lines

>>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