4 ms·
and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1] 1. https://lkml.org/lkml/2014/1/21/361 https://lkml.org/lkml/2014/1/21/361
by Anunayj 4y ago
and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1]
1. https://lkml.org/lkml/2014/1/21/361 https://lkml.org/lkml/2014/1/21/361
- hinkley 4y agoLinus doesn't appear to be particularly enthusiastic about this strategy. Humans really do handle treating changes as a sequence. I wonder if this was really necessary or could have been serialized.
- HWR_14 4y agoMercurial, by the spec, only allows two parents to force merges like that into a sequence.
- wdfx 4y agoAnd when you are playing around with git to try this strategy and it's not allowed you get the wonderful error message "should not be doing an octopus". (IIRC, from some version of git from about 6 years ago)
- chrismorgan 4y agoThere are realistic uses for more even than that. I’ve worked with a system of pre-production deploying where you labelled your PR/MR/whatever-you-call-it “include-in-beta” or whatever, and the beta branch would be reconstructed to be an octopus merge of the production branch and all include-in-beta heads. (When I came to the process, it was doing sequential merges, which got very slow when you had a whole bunch of work backing up that you couldn’t deploy to production just yet, so I turned it into a single octopus merge which was much, much faster, only falling back to sequential merges if the octopus merge failed, so that it could point out which MR conflicted. I don’t remember how high the numbers ever got, but I think it went beyond 66 at times, even with only a couple of dozen developers.) Graph log visualisation was certainly fairly difficult to make much of, but it wasn’t generally intended to be made much of, since it was basically a deployment implementation detail.