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 [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. 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 enough. > 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. Kevin - 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
