On Mon, Feb 20, 2023 at 7:33 PM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote: > > 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. I would disagree on two points: 1. The need for merging in the upstream varies project by project, user by user, etc. If you are working on a part of a system where you can reasonably assume the ground will not shift under your feet, awesome, lucky you! Many users are not so fortunate, and need to regularly ensure that their changes still make sense in the ever-changing upstream context. Regularly (whatever that means to you) merging in the upstream is the simplest way of achieving that. If you're working on your own or as part of a team that's happy to handle coordinated rebasing, then rebasing is a potentially-more-satisfying way of achieving the same end - either way, assuming that their changes will make sense in the upstream context is simply not a luxury many users can afford over any period of time. Now, you note that Linus advocates for merging specific points, because he doesn't respect you merging "random crap" from a branch called "linus" - that's fine, but many projects strive to keep a specific trunk branch "evergreen" in order to minimize late conflicts are maximize coordination - there's a pretty cool site about it: https://trunkbaseddevelopment.com/ - this is not really different to Linus' advice except that the goal is to make there *never* be "random crap" on the upstream. 2. The fact that the commit history of non-expert git users (those who should not be using rebase, especially in teams) are so often... spidery... is why the "Squash" option of pull requests / merge requests is so popular in centralized workflows (GitHub, GitLab, BitBucket, etc). If your project follows a "merge down, squash up" strategy with a well-CI-guarded evergreen trunk on a central server, there's simply no reason to *require* your users to become rebasing experts - you can let them use simple merge-based workflows, keep your trunk clean by squashing away their complex commit graphs, let them merge down whenever they need or want to, etc. > We might still want to change the default to > better support the more unusual cases, but Do we have any analysis/understanding of how common workflows like that of the git or linux projects are, vs github-style fork-based projects, vs straight-up single central server projects? I'm not sure what you mean by "unusual", but I don't think "avoid rebase unless you really know what you're doing, merge down at will, we will squash your contribution in the pull/merge request at the end anyway" is an unusual flow at all nowadays. > 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. > "teach [...] wisdom" is a good one! No, seriously - of course I'm going to do the best I can to prevent my users from falling into the traps surrounding them - but my point here is that *we simply shouldn't have pointless traps*. Offering a command that can cause significant "harm" (time loss, frustration, etc), silently... just doesn't seem like a good idea. > [1] https://www.mail-archive.com/dri-devel@xxxxxxxxxxxxxxxxxxxxx/msg39091.html > [2] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@xxxxxxxxxxxxxx/
