Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> If we are talking about a drastic change, a few more days may not be >> sufficient, but we are not in a hurry, as this already sounds like a >> 2.18 material anyway. > > It is not at all a drastic change. It will actually make the current patch > series better (simplifying the "can we fast-forward?" check). > > I just want to make sure that I already have Phillip's strategy working, > but it will be yet another topic branch on top of the topic branch that > will add support for octopus merges *after* the current --recreate-merges > topic branch ;-) Oh, if the "not redoing the merge afresh, but attempt to reuse the previous merge" that was discussed is going to be done as an update/addition to the "redo the merge afresh" you already had in production forever (and I had in 'pu' for quite a while in various polished-ness during iteration), then I do prefer merging down what has already proven to be 'next' worthy without waiting for the discussion and your local verification of Phillip's new thing, especially given that you'll be giving an explicit control to the users which variant of "merge" insn will be used and the addition of the Phillip's thing won't be a backward-compatibility issue when it comes later. >> As you made it clear that it is OK not to merge the current one for now, >> my objective of asking the question is already satisfied ;-) > > Depending how much GitMerge will occupy my time, I hope to have something > polished by tomorrow. My "for now" above was just for the coming few days. Don't rush things, and use valuable in-person time wisely, and have fun. Thanks.
