On Mon, Feb 20, 2023 at 6:21 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > > When we teach new folks about git, and get to rebasing, there is a > simple and easy rule to tell users: don't mix merges and rebases. > (There's a minor exception there in that merges with the upstream > branch are fine and rebasing can let you get rid of those otherwise > ugly-and-frequent back-merges that users sometimes make.) Who is "we" here? When I search for the exact text "don't mix merges and rebases" in google, the only hit I get is this very email thread. Without the quotes, I get a similar-looking page title, but I don't understand whether the author's thesis is the same thing you're getting at - I don't think so: https://dev.to/jessekphillips/rebase-and-merge-don-t-mix-4aj > > Obviously, your users are ignoring that advice, and feeling pain. "Ignoring" is a strong (and in my opinion, strange) term to use here. They are *not seeing* that advice, and I think you can reasonably assume that many, or most, users will not see almost any of the advice you can possibly offer. As software designers I believe we all strive to set things up so you need to learn as little as possible to use something usefully, and safely. > To > be fair, the "RECOVERING FROM UPSTREAM REBASE" section of the rebase > manual isn't that prominent, and perhaps your users didn't have more > seasoned developers sharing this don't-mix-merges-and-rebases advice > with them. (It seemed to me to be shared pretty widely and commonly, > but perhaps we are relying on education from others too much and > education is never uniform if not coming from the tool itself.) My equivalent of this is "never rebase a shared branch unless you and your team know what you're doing". For most users I interact with, that translates to "don't use rebase at all unless you have a git veteran standing at your shoulder / on a screenshare with you". This advice is, again, not necessarily something that users even *see* before they start needing to use git. Maybe they should? Should we add a child lock on the executable, "this is likely to do very surprising things, please sign here that you have studied graph theory and really understand how this stuff works before you get to use it"? > I > understand you want to make it easier for users to avoid accidentally > getting into this state. That's a valid concern and desire. I think > we should improve the situation. > > However, on what timetable and at what cost to others? > > You're advocating we start advertising an alternate option, one which > has some caveats and gotchas that are not going to be so easy to > explain to users -- neither to new users, nor to folks who have been > using Git for years. What I'm trying to understand is whether or how these caveats and gotchas are *any worse than the status quo / than the current "pull.rebase=true" behavior*. I haven't understood any clear concrete ways in which this is true yet: * "pull.rebase=merges" throws away your merge conflict resolutions - so does "pull.rebase=merges", right?? * You might find it surprising that a same-merge-point branch gets rebased with the default "-rno-rebase-cousins" behavior... but "pull.rebase=true" will also do that! * You might be disappointed at the fact that an interactive --rebase-merges rebase fills your screen with stuff - but a "flattening" rebase does that too. * You might be disappointed at the fact that --rebase-merges takes a long time when fast-forwarding over the merge of a large amount of history - but a "flattening" rebase does that too. I'm not advocating for experienced users being by any means required to use this functionality in its less-than-perfect state - but I *am* arguing that foisting that less-than-ideal state on people who copy-paste a suggested command from a pull conflict hint is far better than allowing them to accidentally "flatten the history" of upstream-branch commits. > We could just bite the bullet and start > explaining, but these caveats and gotchas are completely incidental to > the implementation, and are in no-wise fundamental to the desired > operation. We already *do* explain, right? We've already retired --preserve-merges! > I believe that switching to this new option is going to > generate an awful lot of questions and surprises by users. It seems > to me to be a really sad state of affairs to be recommending an option > with known defects when (IMO) the solution is known. Can't we fix it > first, then recommend it? I guess maybe I'm misunderstanding your concern: * My main aim is to stop users shooting themselves in the foot * If making --preserve-merges the overall default for "git rebase" is the only or best way as Alex has proposed, great, let's do that. I personally would like to have the "use --rebase-merges by default when using "git rebase" option that Alex is proposing even if we don't do this, but even that is secondary to me compared with the "stop offering a rebase behavior that will cause users to duplicate upstream history unknowingly, at a blocking prompt where you're forcing them to pick *something*" objective that kicked this off. * If there is another, better way of removing this foot-gun, I'm happy to explore another direction Do you have a suggestion? Or would you advocate for *eventually* replacing the foot-gun with a more childsafe tool, when that tool is as sophisticated as we think it should eventually become? > > Granted, this is a trade-off. You have users experiencing real pain. > You want a solution now. I want to not recommend features with known > implementation shortcomings and known solutions, until those solutions > are implemented, and I know that will take a while. What to do here > is a judgement call, and I was merely giving my opinion on the call to > make. Other folks on the list might see things differently than I do. I think there are many options, and I'd love to understand which one you advocate for in the immediate term, with respect to the specific issue I noted: * Replace the pull conflict hint only, as I initially proposed * Engage on an "asap" replacement of default "git rebase" behavior to "--rebase-merges" by default * Change the pull conflict hint in some other way (that removes the copy-paste footgun) * Do nothing, accepting that we will revise all this in some future, and it's been like this for so long, what's wrong with a few more people hitting the classic issues? * Some other proposal for short-term relief of this very specific problem? I should note here, that for "my" users, setting the new config option Alex proposes in "rebase: add a config option for --rebase-merges" by default, in all their repos, is sufficient for me to ensure people will stop hurting themselves, and that's something I can easily do if/when the patch is accepted - but the main reason I hang out here is to try to advocate for users *like* mine, people who use git because it's the best or only game in town, rather than people like me who think it's so friggin awesome and are fascinated to learn all its arcane mysteries. In my environment, that's easily a 10:1 ratio. I suspect that's a reasonable reflection on the universe of git users generally.
