On Sun, Oct 10, 2010 at 05:47:28PM -0400, Davidlohr Bueso wrote: > On Sun, 2010-10-10 at 13:25 +0200, Sami Kerola wrote: > > As a git newbie I found README.devel not to help me sufficiently. > > The changes in this commit are what I would have needed earlier > > i.e. almost holding hand what to do and how. > > Let's remember that this file is not a git-tutorial. Good point. > > I am not quite sure about all I wrote, like the --cc > > kzak@xxxxxxxxxx, or set up your own repository and send pull > > request. Please review with thought before merging. It's upstream maintainer's responsibility to read the upstream mailing list. The --cc is unnecessary. > > + * First get familiar with git. In case you are completely > > + lost watch Greg Kroah-Hartman explaining the very basics. > > + http://archive.fosdem.org/2010/schedule/events/linuxkernelpatch > > So many projects are now using git that it would require all of their > READMEs to have this, again, not necessary. Maybe add something like: > http://lxr.linux.no/#linux+v2.6.34/Documentation/SubmittingPatches I think that add some link (or links) to useful git documentation is a good idea ... > > - * diff -u > > - ... but we shouldn't expect that everyone has to use git. > > * don't include generated (autotools) stuff to your patches > > (hint: use git-clean [-X]) > > > > + * add a Signed-off-by line, use "git commit -s" The "Signed-off-by" is explained in the file. > > + > > * patches are delivered via email only. Downloading them from internet > > - servers is a pain. > > + servers is a pain. The following commands will do the correct thing. > > + > > + $ git format-patch -C origin/master..yourbranch -o ~/patches > > + > > + When you send only one patch use the following. > > + > > + $ git send-email --to util-linux-ng@xxxxxxxxxxxxxxx \ > > + --cc kzak@xxxxxxxxxx ~/patches/0001* > > + > > + The command above expects you have configured email sending properly. > > + See git.wiki for help. > > + https://git.wiki.kernel.org/index.php/GitTips#Mail A simple hint about "git send-email" + URL to docs is good idea, but nothing other is necessary. > > + $ git send-email --compose --to util-linux-ng@xxxxxxxxxxxxxxx \ > > + --cc kzak@xxxxxxxxxx ~/patches/000* > > + > > + Good introductory message will have at least > > + > > + -- snip > > + Your Name (3): > > + firstfile.c: short description > > + secondfile.c: another description > > + > > + firstfile.c | 2 +- > > + secondfile.c | 2 +- > > + secondfile.c | 2 +- > > + 2 files changed, 3 insertions(+), 3 deletions(-) > > + -- snip > > + > > + Above introductory can be generated with git. > > + > > + $ git shortlog master..yourbranch > > + $ git diff --stat master..yourbranch > > + > > + * Subject: [PATCH] subsystem: description. Following ~/.gitconfig will > > + help you a little. > > + > > + -- snip > > + [user] > > + name = Your Name > > + email = your.name@xxxxxxxxxxx > > + > > + [format] > > + subjectprefix = PATCH > > + numbered = auto > > + signoff = yes > > + > > + [sendemail] > > + chainreplyto = false > > + cc = your.name@xxxxxxxxxxx > > + -- snip > > Again, the file is not a git-tutorial. Yes. > > + > > + * for more than 9 patches set up your own git repository, reachable > > + from internet, and send pull request Unnecessary rule. I prefer common sense, so I'd like to minimize numbers of rules and maximize number of responsible people who are able to work without strict rules. Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
