Ned Batchelder <n...@nedbatchelder.com>: > I feel like I am misunderstanding you. My summary of what you just said > is, "I have two scenarios where my code went through different sequences > of changes to end up with the same content. I expect both of those > paths will show the same history." That sounds nonsensical to me, so I > must be misunderstanding you. The path the file followed (that is, the > sequence of changes that made the file what it is), *is* the history of > the file.
Not the file but the repository. 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. With TeamWare, Bitkeeper(?) and CVS the process is simple since they retain the file scope. Propagating a fix from HEAD to 3.0 is equivalent to propagating a fix from 3.0 to HEAD. After the pull/push, if you look at the version history, you couldn't say which way the process went since the pull/push operation itself doesn't leave a trace. (Well, in CVS, it does, but that's bad.) In large repositories (like CPython), you have independent modules with relatively independent (and typically linear) histories. Hg and git don't want to respect that independence. As I said before, the problem is alleviated or goes away if you split your large repositories into tiny repositories. Then, looking at the example above, you could have a collections repository. CPython 3.0 and 3.9 might use the same version of the collections component. The bug would then be fixed in collections and both CPython 3.0 and 3.9 would simply update their component dependency to the latest and greatest collections. Marko -- https://mail.python.org/mailman/listinfo/python-list
