Hi Junio, On Thu, 8 Mar 2018, Junio C Hamano wrote: > 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. I would like to stress that the `--recreate-merges` functionality has *not* beed in production forever. It is a reimplementation in pure C of the Unix shell script that has been in production for five years (unchanged only for the last half year, the last critical fix happened in January last year). So I do see the value here to use `next` as test bed, and once the patch series will hit `next`, I will also merge it into Git for Windows (as an EXPERIMENTAL feature). As such, I am quite comfortable with refactoring a bit here and there, for example how to handle the case where a `merge` can be fast-forwarded. I think the changes I made in the last few days were an actual improvement to readability, even if the only reason for those changes was that I wanted to accommodate the "rebase merge commits" thing. FWIW I am fine with bumping this down to 2.18. I got a little bit of valuable feedback at GitMerge, e.g. that --recreate-merges does not (yet) have a mode where it can update refs corresponding to the rebased commits. (This could actually turn out to be independent of --recreate-merges, even). I already pushed out the updated branch, and it can be inspected at https://github.com/git/git/pull/447 The reason I did not send this out yet is that I want to give it a final look-over myself, so that I do not waste people's time again (as I did with that monster interdiff that was pretty bogus, too). Ciao, Dscho
