On 03/21/2014 11:56 AM, Pasquale Dir wrote: [please don't top-post on technical lists] > That seems a little complicated...sorry but I never used git in this way > and I have very little time to learn this too. Learning how to get 'git send-email' to do the right thing will generally save you more time in the long run than it costs in the short term to learn it. > > They are just 3-4 source files, if someone can handle this for me I'd be > happy to send them so they can upload in the right way. The problem is that "upload in the right way" is best done by smaller incremental patches, not giant patch bombs. We don't like taking code that is unreviewed, but reviewers don't like reviewing giant blobs of code. It is in EVERYONE'S best interest to split patches into smaller chunks. > Sources are less then 150Kb, that is for sure...if I send you a .rar with > the sources would it be ok? No. Send the patches directly as plain-text attachments legible inline with the mail, the way 'git send-email' does it. Looking over past archives of the mailing list will show you examples of what forms a good patch. Doing it any other way merely serves to obscure the patches, and reviewers tend to not want to spend time digging out an obscure patch. Unpacking a .rar file just to get at the source patch is not my idea of fun, in comparison to just reading it in my email client. Which goes back to the premise above: the right way to get code in is to get it reviewed, but if you make the reviewer's life hard, it won't get reviewed, and therefore won't get in. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list