bug-inetutils
[Top][All Lists]
Advanced

[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


From: Guillem Jover
Subject: Re: [bug-inetutils] [PATCH] Use socklen_t instead of size_t to fix warnings on 64 bit builds
Date: Sun, 6 Dec 2009 07:57:12 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, 2009-12-04 at 09:38:05 +0100, Giuseppe Scrivano wrote:
> 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.

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”.

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.

thanks,
guillem




reply via email to

[Prev in Thread] Current Thread [Next in Thread]