| 00:36 | <bakkot> | in theory, yes - that's what "squash and merge" does. but ljharb has a strong preference for force-pushing the PR branch to have exactly the commits which are going to land, for reasons I am now forgetting. |
| 00:55 | <ljharb> | Because the PR ref remains forever, and because if it deserves to be a separate commit in the PR, it deserves to be one in main. |
| 02:47 | <jmdyck> | I disagree. I think it's useful to have different levels of commit granularity in main vs PR. |
| 02:48 | <jmdyck> | (or at least, different levels of commit granularity available _some_where, and I'm not sure where that would be other than the PR) |
| 03:20 | <jmdyck> | Moreover, "deserves" according to whom? I determine what deserves to be a separate commit in my PRs. Are you saying that my choices for the PR should determine what constitutes a commit for main? If so, there will be a lot more fine-grained commits in main, which (a) is probably not what the editors want, and (b) is probably not even what I want in main. |
| 19:48 | <jmdyck> | E.g., re https://github.com/tc39/ecma262/pull/2716, I'd be fine with that being a single commit on main, because that seems like the appropriate level of detail for most people going through main's history. But if someone is interested in that particular commit (e.g., because they don't understand something, or find a possible bug), then I think it could be helpful to have the PR decompose that commit into a series of smaller commits, with more focused commit messages. (Not the 13 that are there now, but a tidied-up set of 6.) |