We will be moving to GitHub

[Chris Angelico]

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, and doesn't give you the other
two choices. The price you pay for power is complexity. But with a
little bit of tooling, you can hide that complexity from day-to-day
usage - it means writing a git hook, but don't be scared off by that;
they're just simple scripts!

ChrisA