Hi,
so I have been sending commits to the git mailing list occasionally
for quite some time. In the last couple of weeks I send more and more
patches to the mailing list as it's part of my job now. Here is a
collection of practices I am following (or want to follow) and they
seem to be effective.
Most of this is already documented in various documents in Documentation/*
and this email is no news for the regular contributors. It may help new comers
though.
* Split patches up into logical pieces as you go.
It's easy to go wild and after hours of hacking you have implemented a cool new
feature. This the natural flow of hacking as it's the most fun. But
this approach
is not easy to be reviewed. So let me explain how reviewing works in
the git project.
Reviewing works in the git project is quite liberal, anybody
is encouraged to
comment on patches flying by. Junio, the maintainer then
decides which patches
he picks up and merges them into the various stages of git
(pu, next, master, maint).
The decision which patches are worth for inclusion is based on
the amount of discussion
by the community and generally a patch only makes it if a
concensus is met.
* git send-email is the only email client I trust for sending patches
While mail clients such as Thunderbird or the gmail interface are optimized
to be used by everyday people it behaves differently than you would expect.
For example these mail clients may convert tabs to white spaces depending on
the configuration. The default configuration is usually not sane.
To avoid that I tend to use git send-email only when sending patches
to the list.
Here is my setup:
git send-email needs a SMTP client to talk to a server, as I am using Ubuntu
I need to "apt-get install msmtp". Then there is a configuration file
.msmtprc which reads:
defaults
tls on
# this may be different in other distributions:
tls_trust_file /usr/share/ncat/ca-bundle.crt
logfile ~/.msmtp.log
account gmail
host smtp.gmail.com
port 587
from <yourname>@gmail.com
auth on
user <yourname>@gmail.com
password <yourpassword>
# Set a default account
account default : gmail
The git configuration for sending email via msmtp is
git config --global sendemail.smtpserver /usr/bin/msmtp
git config --global sendemail.smtpuser <yourname>
git config --global sendemail.from <yourname>
* Keep notes between different versions of your patch
Look into the man page of git notes for the configuration variables. The only
thing requried should be
git config notes.rewriteRef refs/notes/*
to enable keeping notes during a rebase.
* Make sure you're not embarassed by the patches you send out
I fail this talking point often. Write a patch or incorporate
just a one line fix and send it off to the list. What could go wrong?
One line fixes and small patches tend to look so easy that you forget
to compile check or run the test suite, which then promptly breaks.
To prevent such disasters, I want to do a:
git rebase origin/master --exec=make --exec="make test"
before sending the patch series to the list.
* Wait with sending out iterations of patches
"patience is a virtue I do not have"
So you successfully send your patches to the mailing list. By
successful I both
mean it worked technically as well as you got actually reviews and comments.
Usually the comments are feedback how to improve the patch. Now it's easy to
fall in the trap and fix all the problems the reviewers point out and resend
the patches again to the list again.
Waiting for roughly 24 hours helps a lot I found out. This brings
you the following
advantages:
* You may get more comments from people in other time zones.
Git contributors
are quite international folks. So it would be impolite to not wait for
everyone to at least have a look at it. They might be
sleeping currently.
* You will find yourself reviewing your patches twice. Once after fixing
all the problems the review unveiled and once again before sending out
the new iteration of the patch series.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html