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