We will be moving to GitHub

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> I don't think you understand the meaning of "merge conflict", then. A
> merge conflict is when you cannot simply merge the changes.

A conflict is when there have been two parallel changes to the same
versioned target. In the case of Hg and Git, the whole repo is the
target.

> If the changes are on separate files, neither git nor hg will find
> this to be a conflict, and the merge will happen automatically.

They can propose to resolve the conflict automatically, which, BTW,
undermines the very idea of treating the whole repo as an atomic target.

Hg and Git think it's too dangerous to trust changes to individual files
are independent, but then, the alleviate the resulting pain, they offer
to treat the changes independently anyway, giving you the downsides
while sacrificing the (purported) upsides.

> Alternatively, you can rebase rather than merging (git's term;
> Mercurial has a similar concept for saying "put my private changes on
> top of the history", but I can't remember the name), which again will
> succeed automatically if the changes are to different files. Even
> better, the merge/rebase will generally succeed even if the changes
> are to the same file, as long as they're to different parts of it.

In Teamware, push ("putback") will simply succeed without any need to
resolve the merge conflict (automatically, or otherwise).

> Play to a tool's strengths rather than its weaknesses, and you'll find
> life a lot less frustrating. I'm fairly sure you could use the same
> workflow with git as you were accustomed to with Teamware, only with a
> few different names for things. And most likely Mercurial too, but
> again, there'll be different names. Maybe you'll use branches for what
> you used to use forks for, or maybe you'll have multiple clones of the
> same repository, or maybe some other arrangement. Get to know some of
> the myriad ways you can use modern source control systems, and find a
> workflow that suits you.

As I said, the problem is nonexistent when your repositories are tiny (~
5-20 files) and each is actively maintained by a single person.


Marko