On Sun, Feb 5, 2023 at 9:41 AM Tao Klerks via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > From: Tao Klerks <tao@xxxxxxxxxx> > > 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 <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.) 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@xxxxxxxxxxxxxxxxxxxxx/msg39091.html [2] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@xxxxxxxxxxxxxx/
