On Sun, Jan 3, 2016 at 1:52 AM, Marko Rauhamaa <ma...@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 -- https://mail.python.org/mailman/listinfo/python-list
