That's an interesting idea. I happened to be interested in the diff algorithm recently and think they are related. A fundamental problem of the diff algorithm is, it does not track line moves. As long as our diff algorithm cannot do that, I won't do the merge thing manually.
Will that kind of "smart" diff algorithm exist? Probably. And if we can have the diff algorithm which detects moves (I'm in dreaming mode), and new version of revlog (probably will contain both the new diff algorithm, and some kind of packing to reduce inode), it will help making deltas smaller. And I don't think the "move" information has to be hashed / committed. It could be calculated afterwards and store separately. (this also means I think the git data model is cleaner). Excerpts from timeless's message of 2016-11-23 21:36:02 -0500: > fwiw, it is possible to keep blame for this if you really wanted to. > > The approach is: > 7ef2ebf5cdf91192a66b461ff56f653a65e65dd7->x > x: > copy scmutil.py -> scmutil_.py > 7ef2ebf5cdf91192a66b461ff56f653a65e65dd7->y > y: > copy dispatch.py-> scmutil_.py > delete lines from scmutil_.py > > x+y->z > z: > resolve merge conflicts in scmutil_.py as in this patch > delete scmutil.py > rename scmutil_.py -> scmutil.py > delete lines from dispatch.py > adjust dispatch.py as in this patch > > If you do it this way, commits `x` and `y` still build (they just have > temporary files scmutil_.py which isn't used), and you still have > blame for scmutil.py for both parts. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel