On 28/02/13 19:45, Laine Stump wrote: [...sni[...] > > I think Eric mentioned elsewhere that your patches are *extremely* > small. At least both the data structure, parser, and formatter changes > should go into a single patch. For that matter, this functionality is > small enough that you could put the struct change, parser change, > implementation of the feature in bridge_driver, makefile and configure > changes, AND the documentation addition into a single patch. Yes. Remember this an RFC so to some extend I'm making it easier to document (in commit messages as well as logical separation of the patches), the way I thought about the problem for myself as much as anyone else. When I'm developing a feature for some package that is foreign to me I prefer to break each focus of change into the actual hacking style I follow, which allows me to go back and change patches that have a single focus without changing related code (which may also be in a related branch where I'm testing alternate functionality) using, f.e: git rebase -i HEAD^^^^^^ s/^(pick) (49fe52|3f98634)/edit \1/ while $SOME_FILE; do vim $SOME_FILE git commit --amend git rebase --continue done Once the patch-set works and has positive feedback I can squash cherry-picked commits into a new branch for the final: git request-pull branch_x -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list