I agree with you in spirit (people need to learn their tools more) but your examples...not so much. Merging main into the feature branch was the original intent on how to do it. PRs are sent the way you describe because GitHub literally offers the maintainer a squash option and it's a lot easier to review a pull request when history is unedited.
PR should be sent to review in a state that author considers ready to merge. Assuming it will be squashed and taking that as a reason for submitting dirty history is just sloppy and unrespectful.
Merging is for keeping track of a group of commits that has been taken from a feature branch and included in the mainline. Why would you clutter the feature branch with periodic main merges when you can cleanly rebase it and keep it tidy?
> Merging is for keeping track of a group of commits that has been taken from a feature branch and included in the mainline.
Merging is for bringing a group of commits from branch A into branch B. It is, quite literally, the original way to perform this operation. It's not "clutter", it's a correct picture of how the code was developed.
It's clutter because it adds no information value on a short lived branch. If it's a branch that periodically syncs with another it's ok, if you're just basing off current master for a feature branch rebase is the way to go.
I've developed branches against a moving target all the time where the moving target introduced a problem in my code that wouldn't have been found by a simple merge conflict resolution. It's much much easier to find the source of the problem when you have the real history (a merge) instead of a rewritten history (a rebase).
> it's a lot easier to review a pull request when history is unedited.
Ist it really? If you would See my uncleaned history, it would take you days to understand what I was even trying to do.
Your statement seems based on the assumption that someone knows how to achieve a particular thing right from the start. But that isn't always the case and there might be a lot of different approaches until the correct or best one is found.
Do you really want to review dead code that's somewhere in the commits of a feature branch?
Yes, I'd much rather review a PR with the full unedited history, not the history that the submitter thinks is good or pretty. You often don't know what information you need until you need it. I'll take the entire, dirty history, and once I'm done with it it can be squashed.
Can we take a step back here and ask what point you are trying to make?
A user (who wasn't you) called me out for talking about GitHub instead of git, and I said it was perfectly fair because the original discussion was specifically about sending pull requests, which is a term we only talk about in 2024 because GitHub made it a thing. Therefore, it's entirely fair to discuss it in the context of GitHub and not git.
Now we are five posts down into this bizarre tangent and I am unsure what point, if any, you are trying to raise here. That people now use the term pull requests when not using GitHub? I don't think I've seen it anywhere except for hosted services, but my experience is not universal.
We don’t have to rehash things. Let’s chalk it up to me getting some wires crossed. (It took me until writing half of the original reply to realize. Hah!)
Linus Torvalds needs the merge operation as an integrator.
Considering the email workflow of the kernel I can’t really make sense of “intended way to do it”. For individual commits people send out patches. I’ve never seen an email thread where some merge topology is recorded: it’s just a list of patches. A straight line.
I’m pretty sure that people used patch queues before Git (and even now with quilt). Restacking a bunch of commits on top of the mainline is the same operation as a rebase.
I’ve certainly seen Linus get mad at another maintainer for allowing a back-merge into his history (merge main back into feature branch).
