This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deTLDR: Tried to find another way of managing changes to a large patch on gerrit by submitting a merge-commit, but turns out not so useful. Just sharing findings. When I fix and change the current large osmo-bsc refactoring patch, on the one hand I'd like to squash new changes into it to commit the correct result right away. On the other hand, I want to keep the new changes in separate reviewable bits, so that reviewers don't need to read the entire patch again, and so that the new changes can be reviewed one by one, separately. So far my strategy was to add a new patch set for each small change. Now I thought it might make sense to have a non-fast-forward merge combining commits and review that. I tried it in the sandbox repos. Turns out that gerrit will have one patch for the merge-commit including the smaller commits, showing all combined changes. However, there will also be separate patches in the list for each single part of that merged commit. So there will be a series of small commits onto current master that need to be reviewed and merged one-by-one. And in the end that is followed by one basically useless merge-commit; meaning, if we got as far as accepting the smaller parts of that merge, we don't need to also merge that empty merge-commit, master already has gotten the smaller bits as separate commits. So the conclusion is that indeed pushing new small patch-sets onto the same large commit makes the most sense, and where changes stand on their own, separate follow-up patches make sense. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180719/6172d894/attachment.bin>