On Fri, Aug 29, 2014 at 2:17 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: > Imagine we have CPython 3.9. It might have an ancient implementation of > the deque. Then somebody realizes there's an embarrassing bug that > requires a simple fix in a C file. The fix is implemented in HEAD. Then, > it is propagated down to 3.9, 3.8, ... 3.0. You obviously couldn't use > "hg pull" for the propagation since hg would insist on propagating all > the unrelated features as well.
What you're saying, though, is that there's something inherently special about file boundaries. You want files to be magically separable within a repo. Why? What's the significance of the file? In reality, it's highly unlikely that this simple fix is the only change that's ever occurred to that file, so I very much doubt that your proposal would even work. With git/hg, the merge is exactly the same whether there've been changes to other files or changes to other parts of the same file, because file boundaries just aren't that special. This is basically a cherry-picking job; I know how to do it in git (git cherry-pick some_commit_reference), although I'm not sure the best way in hg - a quick Google search suggests 'hg graft', but at very worst, all you have to do is export a patch and reimport it. Chances are it'll apply cleanly even in cases where your proposed magic wouldn't work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
