On Tue, Feb 21, 2023 at 7:01 AM Tao Klerks [off-list ref] wrote:

On Mon, Feb 20, 2023 at 6:21 PM Elijah Newren [off-list ref] wrote:

quoted

[...]

quoted

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.

quoted

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.

quoted

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.