On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > >> I also agree (in particular with Buga) that from the POV of user > >> experience the method suggested by Phillip should be superior. > >> [...] > >> Even this would be a huge step forward compared to silent > >> drop of merge commits and blindly re-merging of updated parents. > > > > I'm not so sure it's a huge step forward. Or even a step forward. > > Git currently throws away my precious merges! Silently! How it's not a > step forward to stop doing this?! Sorry for getting that heated :) I totally agree with you that we have a big problem. No need to convince me on that. :-) But having a big problem does not imply we have to implement and ship the first proposal that comes along to change things. Or second, or third. Such proposals might actually make things even worse. You correctly point out that we do not need to require perfection, but we can and should require that the proposed solutions not only make some things better but that they make things better overall. And in order to convincingly persuade others to adopt various proposals, we should be aware of what the advantages and shortcomings are...at least the ones that have already been discovered and publicized, and be able to talk about those shortcomings candidly. > As for Dscho results specifically, I've got an impression that he never > needed rebasing of merges in the first place, and re-merging always > suited him just fine, so it'd be rather a surprise if rebasing of merges > suddenly started to work better for his needs and workflows once he has > implemented it. Are you serious? You're claiming the author of --preserve-merges; and the author of --rebase-merges; and someone who actually implemented the ideas you, Buga, and Phillip were all discussing to improve rebasing of merges[1]; and who maintains a project (Git for Windows) that has countless branches with hundreds of commits and myriad merge points and needs to rebase the whole lot as Git is updated...is someone who doesn't actually care about rebasing of merges? I thought you had tried to read up on this subject and were commenting in good faith, but I'm starting to have my doubts. Please, go read at least [1] to see Johannes comments about how the prior proposals don't work beyond simple cases. He didn't discard those ideas because he didn't care about the useful information in merge commits, he discarded them because in practice those ideas resulted in behavior that was *even worse* than the current big problems. [1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.1804130002090.65@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ [...] > for now I do believe we need something > reliable that has been checked to actually work for common cases, as > blind re-merging simply does not. I agree with you. The word "reliable" is particularly key, and IMO rules out any suggestion that involves applying the diff between a merge commit and either of its parents. Not only do I think it's the wrong solution theoretically, I also think they have empirically been shown to provide problems that many will consider to be as bad or worse than our current poison. I obviously don't have veto power or anything close to it, but in my opinion any solution based on those ideas do not meet the threshold bar for inclusion in Git and I'll raise my voice against them. Solutions based on other ideas are fair game. Heck, I've proposed one and I know of simpler variants to my proposal. Other solutions may exist too. But can we stop pushing already discredited proposals and instead reach for something that has a more solid foundation?
