Brian Foster <brian.foster@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx/msg39091.html
Incidentally the message explains why it would be bad if your
"now-and-then" above is too often.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html