Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Marko Rauhamaa Newsgroups: comp.lang.python Subject: Re: We will be moving to GitHub Date: Sun, 03 Jan 2016 02:33:26 +0200 Organization: A noiseless patient Spider Lines: 50 Message-ID: <8737uf1oyx.fsf@elektro.pacujo.net> References: <5687718d$0$1612$c3e8da3$5496439d@news.astraweb.com> <87oad41fd4.fsf@elektro.pacujo.net> <87k2ns1b0d.fsf@elektro.pacujo.net> <87ege012i5.fsf@elektro.pacujo.net> <87a8oo11b4.fsf@elektro.pacujo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="b7cb1518d23ec19d482dcc9c31d30fdd"; logging-data="10865"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/+gDOm8NUy4bUySrPXiR8i" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:r5BdT2BNqlIoL+z8NAwMC+ghsAw= sha1:vA+BzHCP+VYnvJ99FANk81C12AU= Xref: csiph.com comp.lang.python:101178 Chris Angelico : > On Sun, Jan 3, 2016 at 1:52 AM, Marko Rauhamaa 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