We will be moving to GitHub
Marko Rauhamaa
marko at pacujo.net
Sat Jan 2 19:33:26 EST 2016
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
More information about the Python-list
mailing list