We will be moving to GitHub

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> On Sun, Jan 3, 2016 at 1:52 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Terminology aside, if I do this with Git:
>>
>>        -----+--------------------+-------->
>>              \                   ^
>>               \pull             /push
>>                v               /
>>                +--------------+
>>                      edit
>>
>> everything goes in without any further ado.
>>
>> However, this operation will be blocked by Git:
>>
>>
>>        --+--+--------------------+----+--->
>>           \  \                   ^    X
>>            \  \pull             /push/
>>             \  v               /    /
>>          pull\ +--------------+    /push
>>               \      edit         /
>>                v                 /
>>                +-----------------+
>>
>> Not so by Teamware as long as the pushes don't have files in common.
>
> Ah, I see what you mean.
>
> That's a constantly-debated point, and it's actually possible to make
> git accept this, although it's not a normal workflow. Instead, you
> just 'git pull' (possibly with --rebase) before you 'git push'. You
> either create a new merge commit, or make it very clear that you are
> changing your commits to pretend they were committed after the
> already-pushed ones. Or you do a force-push and discard the other
> commits (this is correct if you amended a commit). You HAVE to choose
> because these are three viable solutions, and only a human can make
> the decision.
>
> Teamware presumably picked one of them,

Teamware didn't have to pick any of them since Teamware's commits were
done per individual files. The repository didn't have a commit history.

Thus, Teamware was equivalent to Hg/Git with each file treated as an
independent repository.


Marko