On 08/11/2015 01:49 PM, Rich Freeman wrote: > On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric <kentfred...@gmail.com> wrote: >> On 11 August 2015 at 20:57, Tobias Klausmann <klaus...@gentoo.org> wrote: >>> >>> The cat/pn rule is tricky anyway: what if one commit touches 100 >>> packages? Or should that be split into 100 commits for easier >>> partial rollback? >> >>>> **if the change affects multiple directories**, but is mostly related to a >>>> particular subsystem, then prepend the subsystem which best reflects the >>>> intention (e.g. you add a new license, but also modify >>>> profiles/license_group > > ++ > Go read the proposal. This email chain simplifies it but people have > already thought of most of those corner cases already. > > However, I do want to touch on this bit from the previous email: "Or > should that be split into 100 commits for easier partial rollback?" > > Each commit should be one logical change. If you stabilize 100 > separate packages in an afternoon, there should be 100 commits. If > you stabilize kde-5.0 there probably should be one commit that touches > 100 packages. Likewise if you rename a package and fix 100 references > to it in other packages, that should probably also be a single commit > (but I'd separate renaming the package from any other changes to the > content of the package). > > That is actually one of the advantages of git. You can stabilize > kde-5 and a user doing an rsync will either get kde 4.x or the full > kde 5, and nothing in-between. > > But, one commit in the final tree should still remain one logical change. >
Right. In addition, we just took the freedom to add the clause "all commits must be repoman-valid": https://wiki.gentoo.org/index.php?title=Gentoo_git_workflow&diff=352978&oldid=352858 That will be necessary too for the CI work mgorny is doing and will also make bisecting and cherry-picking easier. That is: if splitting up a commit into several makes repoman fail on some of them, it probably should be one commit instead (or you have to reconsider the order you commit stuff in... e.g. first add the license and then the package). But we are drifting OT again.
