On Sun, Feb 5, 2023 at 9:41 AM Tao Klerks via GitGitGadget
[off-list ref] wrote:
From: Tao Klerks <redacted>
Unfortunately, this rebase configuration can easily lead to non-expert users
accidentally rebasing not their own commits, instead others' commits, if the
new commits they have locally before the "pull" include a merge of another
branch, eg "main".
On Mon, Feb 20, 2023 at 10:21 AM Elijah Newren [off-list ref] 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.)
The "minor exception" is merging a topic branch into main, right? And
the "ugly-and-frequent back-merges" are the merges from main into a
topic branch?
Tao, the primary motivation behind the `git pull` warning was to help
prevent users from merging main into a topic branch when that's not
what they really want to do. The fact that novices sometimes do that
has been a point of pain for many people, including Linus Torvalds:
See "Don't merge upstream code at random points" at [1] and "github
creates absolutely useless garbage merges" at [2].
If you're seeing users merge main into topic branches without a good
reason, that does sound like more of an education problem than a
bad-defaults problem. We might still want to change the default to
better support the more unusual cases, but if you're going for a quick
win, it would be faster to teach users the wisdom of not mixing rebase
and merge in the first place.
-Alex
[1] https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
[2] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/ (local)