Re: How to properly send patches

[Jakub Sejdak <jakub dot sejdak at phoesys dot com>]

There is also one more thing - we were internally working on some
"copy" of newlib-cygwin repository on our server, where we could
freely create branches, commit and push. Now I just applied everything
we have to my local clone of newlib-cygwin as one commit. So
format-patch will actually create one enormous patch. I was looking
for a way to create one patch per new file (even in the same commit),
but this will still generate ~150 email notifications for everyone one
the mailing list.
So final question: multiple small patches and many emails or just one
copressed patch?

2016-04-08 22:09 GMT+02:00 Mike Frysinger <vapier@gentoo.org>:
> On 08 Apr 2016 10:35, Corinna Vinschen wrote:
>> On Apr  7 13:53, Mike Frysinger wrote:
>> > On 07 Apr 2016 13:42, Jakub Sejdak wrote:
>> > > I'm representing Phoenix Systems company. We are developing
>> > > Phoenix-RTOS for IoT.
>> > > We use newlib internally with our changes and now we want to make it public.
>> > >
>> > > However, basing on the mailing list history, I'm a bit confused with
>> > > the procedure of sending patches.
>> > > I guess everything should be send via mail in a form of git diffs.
>> > > Some people paste it into message, some people attach files.
>> >
>> > use `git send-email` to do it the right way.  if it's too big, the
>> > fallback is to use `git format-patch` and compress+attach it.
>> >
>> > > Could anyone instruct me how should I do it properly? I have my
>> > > changes applied to repo cloned with read-only access.
>> > > Since this will be our first patch, it will be huge (141 new files).
>> > > Should I generate diff one for all changes or separate diff files for
>> > > each modified file.
>> >
>> > if it's for a new port, a single patch that adds all the new code is
>> > fine.  you might want to break it up across projects -- one for newlib,
>> > one for libgloss, etc...
>>
>> Actually it would be really nice for reviewing to split it also in
>> as many independent parts as possible.  That also simplifies to find
>> a bug via bisecting.
>
> while a general truism, i don't think it matters for new ports as much
> when you're basically adding a ton of files.  you can't really bisect
> beyond "initial port".
> -mike