hg, git, fossil, ...

Ned Batchelder ned at nedbatchelder.com
Thu Aug 28 11:39:07 EDT 2014


On 8/28/14 1:58 AM, Marko Rauhamaa wrote:
>
> The main problem with hg (and git) is the way cherrypicking is done.
>
> See these graphics:
>
>   [1]   Product-Ver1
>              |
>              | bugfix
>              |
>              V          feature development
>         Product-Ver1' ----------------------> Product-Ver2'
>
>                         feature development
>   [2]   Product-Ver1 -----------------------> Product-Ver2
>                                                    |
>                                                    | bugfix
>                                                    |
>                             cherry-picking         V
>         Product-Ver1' <---------------------- Product-Ver2'
>
>
> My beef is this: The starting point and end result of [1] and [2] is
> identical. The version histories of Product-Ver1' and Product-Ver2'
> should usually also be identical. In hg and git, they are not. In CVS,
> they are not. In SVN, they are not.
>
> In TeamWare (and bitkeeper?), the version histories are identical.
>

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.  If two different sequences of changes can result in the same 
history, then one (or both!) of the histories are "wrong" in that they 
don't accurately reflect the sequence of changes that happened.

Maybe you can elaborate?

-- 
Ned Batchelder, http://nedbatchelder.com




More information about the Python-list mailing list