Ray Lee wrote:
> On Mon, 2005-04-18 at 21:04 +0000, [EMAIL PROTECTED] wrote:
>>The other is "replace very instace of identifier `foo` with identifier`bar`".
> That could be derived, however, by a particularly smart parser .
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. You could guess, but that's not good
enough for darcs to be able to reliably commute the patches later.
I am curious whether Linus's suggestion about including the
corresponding darcs patch id in the git commit comments would be good
> As for "darcs mv", that can be derived from the before/after pictures of
> the trees.
Perhaps. If a file is moved and edited within the same commit, I'm not
sure that you can be certain whether it was done with d 'darcs mv' or
not. Requiring separate checkins for the rename and the subsequent
modify would make things easier on SCM's, but is impractical in real
life. Automated refactoring tools, for example, perform the
rename+modify as an atomic operation.
Now, git might not need to deal with any of this, because it only needs
to work with the kernel project. But darcs does have to deal with this
wide range of uses, as does just about any other SCM.
I'm *not* advocating cluttering up git with features that are not
directly needed for kernel development. I'm just trying to clarify the
facts so everyone can understand what darcs is trying to do.
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