Sverre Rabbelier <srabbelier@xxxxxxxxx> writes:
> Heya,
>
> On Thu, Jul 29, 2010 at 13:10, Joshua Juran <jjuran@xxxxxxxxx> wrote:
>> How about if you had two (or more) components with a shared protocol, and
>> you updated each to speak a new (and incompatible) protocol. The changes to
>> each component might be done in separate topic branches, but you'd want to
>> merge them all at once.
>>
>> $ git checkout master
>> $ git merge client-v2 server-v2
>
> Very nice example, but do we have it _documented_ anywhere? If not, it
> would be great if you could add that somewhere :)
Please don't.
I actually do not think the "client-server" is a good example from
software engineering point-of-view, as it means that everybody talks
version 1 before that merge and everybody talks version 2 after that
merge, i.e. you have a flag day event.
Think for 5 seconds how one would have tested client-v2 topic alone in
isolation.
The only transition plan that works in real life is for the updated client
to talk fine with a server without version 2 support, while being prepared
to talk the newer protocol if the server supports it. The server side
needs to be arranged in a similar way.
If that is how these topics were developed, you should be able to merge
client-v2 topic and then server-v2 topic, or in the other order, without
breaking anything on the master branch.
The original idea of Octopus was that, when
(1) you have many topics that are not inter-related; _and_
(2) merging all of them in any random order wouldn't have made any
difference in the resulting history, either in the end result nor in
any of the intermediate steps,
it is not worth to serialize the merge order and create extra merge
commits.
I think we tend to discourage the use of Octopus these days, as people are
fallible. When topics that they originally thought are independent turn
out to have funny interactions among each other, having an Octopus merge
across them tends to make bisection much less efficient in order to find
the real culprit in the history when you find something is broken.
Compared to that downside, it is not worth to use an Octopus, only to have
a smaller number of merge commits and a cool-looking lantern-shaped merge
commit in the history.
--
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