hg, git, fossil, ...

[Tim Chase]

On 2014-08-28 19:17, Marko Rauhamaa wrote:
> > 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.

No, you wouldn't use "hg pull" nor "git pull" but rather "git
cherry-pick" or what Mercurial calls "transplant" (I've not used this
in Mercurial, but I believe it's an extension).

That would apply just that patch/diff to the older version rather
than the entire history of changes between 3.{n<9} and 3.9 versions.

-tkc