hg, git, fossil, ...

[Marko Rauhamaa]

Skip Montanaro <skip at pobox.com>:

> The "simple hg commands" are generally not all that different (in my
> limited experience) than the "simple git commands," for some
> definition of "simple." Stuff like clone, init, push, pull, commit,
> the small number of commands you use day in, day out. When you get
> beyond that simple core, both are confusing to me.

I don't think a working VC system needs to contain much more than that.
Hg stays closer to the simple ideal than git, which really fails at
being a black box. I don't see why git has staging or branches, for
example. Or why can't I revert my changes to a file easily?

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.


Marko