git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Tao Klerks <tao@klerks.biz>
To: git <git@vger.kernel.org>
Subject: Defaulting --rebase-merges overall?
Date: Fri, 3 Feb 2023 19:19:00 +0100	[thread overview]
Message-ID: <CAPMMpoj6E-85a59EaHD2aR_oKA=_u78qRV+wp8mqXkR39KctmA@mail.gmail.com> (raw)

Hi folks,

I've had a couple of users recently be bitten by "git rebase"'s
default handling of merge commits:

* One user had selected the "git config pull.rebase true" option from
the "Need to specify how to reconcile divergent branches" pull
conflict hint text, without understanding enough about what that
meant: that if they do a "pull" right after having done a (non-ff)
"merge", their commit history would get mangled with a set of
duplicated commits.

* The other was using a GUI (Intellij IDEA), which offered to rebase
when there was a push conflict, but didn't mention or do anything
special about the fact that the single commit to be rebased on a push
conflict was a merge commit (same consequences)

In terms of "quick wins" to help these users avoid the trap they fell
into, I can think of two "quick wins":
1. Change the "Need to specify how to reconcile divergent branches"
pull conflict hint text to offer "git config pull.rebase merges"
instead of "git config pull.rebase true"
2. Offer a global "--rebase-merges by default" config option (I know
there is already a per-branch option, but that's really not very
effective when people are creating new branches all the time)

I've scanned the archives of the last year or two and can't find any
chatter or activity around this - does anyone have an opinion
regarding either of these approaches?

Ideally I'd like to do both. The hint change for people who follow the
hint without understanding the dangers, and the global config option
for people who understand this historical weirdness of rebase and
would rather see the back of it, now that "--rebase-merges" exists and
improves rebase behavior for most users under most circumstances.
Presumably with such a global config option we would also need a
"--no-rebase-merges" option to counter its effect on-demand?

As I think about it, the global option sounds like it might be hard to
prove the correctness of (and compatibility with the hosts of other
options), so I probably won't be qualified to do this. Is there any
objection to the simple hint change, at least?

Thanks,
Tao

             reply	other threads:[~2023-02-03 18:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 18:19 Tao Klerks [this message]
2023-02-03 21:09 ` Defaulting --rebase-merges overall? Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPMMpoj6E-85a59EaHD2aR_oKA=_u78qRV+wp8mqXkR39KctmA@mail.gmail.com' \
    --to=tao@klerks.biz \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).