3 ms·

Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series be

Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it. It's not an ideal way to operate for most shops, but there's really no reason you can't have a PR/MR/changelist/whatever that is a single branch with X commits on it and you ask the reviewer to review each commit individually instead of as a whole unit (as GitHub and other forges usually expect you to). That and don't let reviews pile up such that you have 5 dependent in-flight reviews, something else is wrong if that's happening.

wredcoll 1y ago
> Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it. What is the advantage to this, other than maybe being easier to send over email? To me, the important part is you have a logical "unit of change" that you're proposing to the codebase, whether that's a single commit or a branch or a jj bookmark or whatever seems more an artifact of the underlying transport layer (email or github or whatever) than any kind of intended functionality of the design.
- packetlost 1y ago
  There's quite a few advantages to having a single commit being the unit of change: - reverts are significantly easier - bisect will work because the code is expected to code/run at every commit - rebase becomes easier in the common case - the transport does not matter, at all. Fully anonymous contributions are possible - commit messages are easier to write because the changes are smaller and more focused Several commits could encompass changes necessary to make a particular feature work (ie. patchset) but because each commit is self contained they can be reviewed and tested individually (in order, usually) instead of a one big diff. It's easier on the reviewer, though there's likely a bit more overhead.

wredcoll 1y ago

> Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it. What is the advantage to this, other than maybe being easier to send over email? To me, the important part is you have a logical "unit of change" that you're proposing to the codebase, whether that's a single commit or a branch or a jj bookmark or whatever seems more an artifact of the underlying transport layer (email or github or whatever) than any kind of intended functionality of the design.

packetlost 1y ago
There's quite a few advantages to having a single commit being the unit of change: - reverts are significantly easier - bisect will work because the code is expected to code/run at every commit - rebase becomes easier in the common case - the transport does not matter, at all. Fully anonymous contributions are possible - commit messages are easier to write because the changes are smaller and more focused Several commits could encompass changes necessary to make a particular feature work (ie. patchset) but because each commit is self contained they can be reviewed and tested individually (in order, usually) instead of a one big diff. It's easier on the reviewer, though there's likely a bit more overhead.