From: Junio C Hamano Date: Wed, 24 Jun 2009 16:31:11 GMT Subject: Re: [Q] `git push', branch management, and "(forced update)"? Message-ID: <7v8wjhwq40.fsf@alter.siamese.dyndns.org> In-Reply-To: <200906241034.18550.brian.foster@innova-card.com> Brian Foster writes: > L is a clone of M, where other work has also been committed, > in master. So now-and-then my colleague pulls M into L: > > o--o--o--o--*--* master > \ > r--r--f--f TOPIC > > My colleague then pushes the result to B. End result is B > is essentially M plus TOPIC. > > As it happens (mostly by design), the changes on TOPIC > are independent of the `*' ones on master. So, working > in L, my colleague often rebases, and this is (always?) > a fast-forward: > > o--o--o--o--*--* master > \ > r--r--f--f TOPIC When he rebases the TOPIC, he is not making this topology. Instead, this is what he is making: r'-r'-f'-f' TOPIC / o--o--o--o--*--* master \ r--r--f--f The tip of the TOPIC before (the rightmost commit on the lower side branch in this picture) is not an ancestor of the tip of the TOPIC after the rebase. It is not a fast-forward. > In a simple simulation test I tried, it not only worked > for me, but the subsequent pull from simulated-B into > simulated-R said the TOPIC was a "(forced update)". > What does that mean? The remote side B (and its mirror R) still points at the rightmost commit on the lower side branch with TOPIC. He forces a non-fast-forward push to B using "+:" (that is "leading plus to force a push" followed by "solitary colon to mean push matching refs"), violating a simple rule "do not rebase what others already have seen". Push from B to its mirror R then will be in the same situation. This may be a good food-for-thought: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html Incidentally the message explains why it would be bad if your "now-and-then" above is too often.