- a big patch :theslinux-makepkg

We will split patches into small chunks, because this is always to
track changes and add new things to the current set.

However, the problem is still there. Imagine there are two different
maintainers who will generate two different sets. By default, :git
will generate patch files like this

 (A) 0001-foo.patch, 0002-foo.patch, ...
 (B) 0001-bar.patch, 0002-bar.patch, ...

Handling this two lists is not easy from the POV of the :ls command.
(We want to help :ls to handle the order of patches/commits.) We may
use a :prefix for each developer. E.g, A uses 1000, B uses 2000
but A must pick another number if he reaches 1000 commits. Complex!

Another way is to avoid using patches. If we may have too many things
to do on the mainstream, we will fork the new project, and we do not
have to keep our eyes on the list of changes. The question is *when
a project is considered as *big**? Okay, just wait. In the first steps,
we will play with patches, and then forking
+ small patch files (from the old big patch file)
PKGBUILD uses small patch files