We will be moving to GitHub
Chris Angelico
rosuav at gmail.com
Sat Jan 2 10:12:44 EST 2016
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
More information about the Python-list
mailing list