Oh! I got it. I missed "generated changes". Well, unfortunately (or fortunately ;) ), I did not meet such a workflow when changes are "generated" without my hands. In your case it may sound reasonable to make separate fixup commit. But Git allows you to make your own (more flexible than SVN, for instance) workflow, which suits you. It's up to you ;) You decide. If you plan cherry-picking that fixups, do separate fixups. Just publish them together. If you want every commit is "clear" and "workable", squash fixup into a single commit. I do not know what exactly is "generated changes" you're talking about ), so, maybe I'd do separate fixups, maybe not. )) There is no single solution. ))) TIMTOWTDI That is why you hesitate :) Do your own decision. And feel free to change it later. )) > To expand on that: To review the change, review the hand-edited > commits, > which is easier when these do not drown in generated changes. Review > the *commands* which generated the rest - I'd put those in the commit > message - and glance at the actual changes. Cherry-pick: Possbly you > need to run the commands instead of cherry-picking the generated > changes. That's easier with a commit with only generated changes. > > I know it also can cause problems. Would you make a single big > commit anyway, and describe carefully in the commit message which > parts are hand-edits? (We don't auto-test commits yet, but I'll sure > this issue will crop up again later when we do.) > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html