Chris Angelico <ros...@gmail.com>: > 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,
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 -- https://mail.python.org/mailman/listinfo/python-list
