hg, git, fossil, ...

[Marko Rauhamaa]

Ian Kelly <ian.g.kelly at gmail.com>:

> On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> I don't see why git has staging or branches, for example.
>
> I use short-lived development branches in git all the time. Start
> working on a bug or feature, checkout a new branch specifically for
> that work.

I do the same thing, but I use forks ("git clone"). Branches and forks
are conceptually almost identical, so why pollute your concept set with
extras?

>> Or why can't I revert my changes to a file easily?
>
> "git checkout <filename>" is not easy?

Unfortunately, that's only half the story. If you have added but never
committed the file, the command is:

   git rm --cached <filename>

I've been in more complicated situations as well.

> Why should they be identical? If they are, then that means they're not
> accurately reporting the actual history of the repository. I don't
> understand why you would even want this.

I don't think the repository should have one, linear narrative. Rather a
large repository has numerous independent narratives.

To quote <URL: http://en.wikipedia.org/wiki/Darcs>:

   Darcs treats patches as first-class citizens. For the user, a
   repository can be seen as a set of patches, where each patch is not
   necessarily ordered with respect to other patches i.e. the set of
   patches is only a partially ordered set. In many cases patches can be
   independently transmitted between various repositories.

   Many branching, merging and cherry-picking operations that would
   require additional commands with snapshot-based systems like Git or
   Mercurial, can be directly done with Darcs with the usual ‘pull’ and
   ‘push’ commands.

   [...]

   Intuitively, a patch B depends on another patch A if A provides the
   content that B modifies. This means that patches that modify
   different parts of the code are considered, by default, independent.


Say you make a change to CPython's GC and I make a parallel change to the
deque implementation:

   common repo ---------------------------------------------------->
        \                                  /          /conflict!
        |\    GC work                     /          /
        | +------------------------------+          /
         \                                         /
          \   deque work                          /
           +-------------------------------------+

Hg and git report a conflict and force me to "merge," IOW, decide which
change comes earlier in the linear history.

A conflict and merge should be rare and hint at development process
problems. In hg and git, they are unavoidable, everyday occurrences. To
put it bluntly, hg and git do not support parallel development.


Marko