hg, git, fossil, ...

[Chris Angelico]

On Fri, Aug 29, 2014 at 2:17 AM, Marko Rauhamaa <marko at 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