hg, git, fossil, ...

[Chris Angelico]

On Fri, Aug 29, 2014 at 3:50 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> 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?

Why fork the repo when you can just branch? That makes no sense.
Nothing's being "polluted" here. Your comment is like pointing out
that separate text files can store documentation, so why have
docstrings and comments?

>>> 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.

So? What you're saying is that the staging area has its own set of
manipulation commands. If git didn't have the staging area, you
wouldn't need those commands. Fine. You can argue that you don't make
use of that particular functionality of git, but it's there, so you
have to cope with it. One easy way is to never "git add" new files
without immediately committing... then it's like lots of other source
control systems.

>> 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.

You completely misuse "conflict", then. This is not a conflict. This
is just a merge. In git, merging *is* an everyday occurrence, and it's
not a problem at all. That's an intrinsic part of the philosophy.
Branching/merging is the normal way to do *everything*. Even if you
think you're not, you probably are. A merge conflict happens when
there's edits to the same or very nearby lines of code, but otherwise,
that's not a conflict at all. And git doesn't force you to choose
which comes earlier in a linear history - the normal merge says "those
two branches start from a common parent, and now have a common child".
That's not linear history at all. Of course, some repos choose to
favour rebasing over merging. I've done plenty of that; where it's a
source code policy to minimize merging - but that's not git's or hg's
rule.

Why are you so dead against merges?

ChrisA