On Tue, Feb 21, 2023 at 7:01 AM Tao Klerks <tao@xxxxxxxxxx> wrote: > > On Mon, Feb 20, 2023 at 6:21 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > [...] > > 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. Yep, fair enough. > > 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! But we didn't suggest either `--preserve-merges` or `--rebase-merges` to general users. The only ones who used it went looking for it. That's fundamentally different than recommending it to all new and many existing Git users. > > 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? My personal opinion is that we should avoid long term problems for users and maintainers of rebasing merges by pushing it too early to too many folks. For short term relief, I would suggest some mixture of the following are worth looking into: * Attempt to improve the message shown to users, perhaps referring them to somewhere in the docs that point out advantages and disadvantages of each choice. * Possibly make the message shown to users be "smart" rather than hardcoded. For example, you could check the local-only portion of history; if there are no merge commits, or if the upstream branch is "origin/main" and the only merges within the local-only history are 'Merge branch "origin/main"...' then suggesting a regular rebase is fine. If there are other merges, then adapt the wording (and perhaps in that special case, actually bringing up rebasing merges is okay, though it'd still be nice if the docs with advantages/disadvantages pointed out its shortcomings). This might be an expensive check, but if only users who haven't configured pull.<whatever> have to pay for it, then perhaps it's a useful thing to spend cycles on. > 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. Yes, I understand. It's frustrating when something you need isn't there and we only have a suboptimal approximation. I want to make things better and have put a lot of time into it; some things that already went into merge-ort were designed around this problem space and I'm planning to do more here. But, also, remember that I'm only one voice among many. Others may disagree with me and agree with you on pushing this earlier.
