[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-inetutils] [PATCH] Use socklen_t instead of size_t to fix warni
Alfred M. Szmidt
Re: [bug-inetutils] [PATCH] Use socklen_t instead of size_t to fix warnings on 64 bit builds
Sun, 06 Dec 2009 06:49:58 -0500
> The patch looks fine. If you want, I can install it.
BTW, when applying patches in git on behalf of someone else, it's
useful to preserve the authorship of the patch by either using “git
commit --author 'Foo Bar <address@hidden>'” when applying them manually,
or with “git am” when getting them from a mail box (which
additionally removes anything between  from the Subject and also
preserves the author date). This way both the committer and the
actual author get recorded, and it makes it way more easier to
track and analyze them using git commands, for example with “git
log” --author or --committer, “git shortlog” to get a list of
contributors, etc. One can always also see both with --format=full
with commands like “git show” or “git log” and similar.
We use ChangeLog for tracking who the contributor is (for copyright
reasons), tracking who the commiter isn't that useful. Many patches
do not follow our standards, so blindly commiting them is out of the
Also you'll find that if people are asked to provide the ChangeLog
entry in the actual patch, you'll usually get conflicts, the other
option, having them in the comments to be transferred later on to
the actual file, imply having to amend the changes after commit, or
use stuff like “git am -i”.
This is not that hard to fix before a commit, we had to do it for CVS
and it is no different now. When sending patches, the ChangeLog entry
should simply not be part of the actual patch. And in many cases we
need to fix the ChangeLog entries, since they are incorrectly
formated, or are missing information. Take the simple example that
you are using one space after end-of-sentence periods, in the GNU
project we use two; so I'd need to fix that before commiting. :-)
Still, for sanity's sake I'd recommend either autogenerating the
ChangeLog at “make dist” time from the git log ouput, and having
normal git one line summary (the one coming from the mail Subject),
and optionally more paragraphs describing why the patch or more
details like error output, etc, and then the normal ChangeLog
formatted entries. Or a bit more revolutionary would be to prescind
of the ChangeLog file, which IMO is a relic from the RCS/CVS times,
tools which were unable to properly record authorship, do aotmic
commits, and be able to analyze and check in a fast way all
previous history. Which seem to be the main reasons exposed in the
GCS for a ChangeLog.
This will simply not happen, one cannot modify a commit log after the
fact, which would produce incorrect ChangeLog entries.
Thank you for your suggestion though, they are most welcome even if we
might not implement them.
PS. RCS did do atomic commits.