On Monday 16 November 2009, Andrew Rogers wrote: > > Do you think that if I were to break this patch down into many really > small patches it would be put into the master openocd branch?
Well, "one humongous patch" won't get merged, so it's got to get broken down into logical chunks in any case. I'd kind of like to see this at least *start* in the 0.5 series. What I'm missing right now is seeing a model for how this will work. I've started to look at the patches from Simon and Andrew; they're both too huge to understand at once (thus un-reviewable and un-mergeable). Note that the point isn't to have "really small" patches. It's to have comprehensible/reviewable patches, usually in a series of chunks that build on each other. Reviewers will look at each one, usually in sequence, and need to have breaks. And for something substantial like this, it's also customary to plan on having multiple iterations ... and quite possibly to see incremental merges. I'll post some technical followup on another thread. > If so, when I 'git commit', my credentials will appear in the log. How > can I best prepare the small patches and ensure that Simon is given the > credit for his own work? Read the git documentation more closely ... what I generally do is "git am" from a patch with "From:" and "Subject:" lines, and only do "git commit" for stuff I've written myself. There are environment variables that "git commit" will use. So far there's not been a lot of traffic for patches I'm comfortable merging right from someone's repository. (I expect that will be happening someday though!) So for now, I want to receive patches as text ... at which point it's easy to edit the text to make sure the changes get properly credited. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
