On 04/06/19 at 04:43pm, Nathan Aclander wrote:
I'm fairly new to using git send-email, so I wasn't sure how to add an explanation to the patch while cleanly separating it from the git commit message. I can speak more to why I found it useful.
Use --annotate and put comments you don't want to end up in the log between the diff stats and the first 'diff --git' line:
Thanks, I will make sure to do that in the future.
More or less, yes. We don't want to have to implement every single option that libcurl provides in pacman, so we try to require a fairly compelling justification before adding them. We are not against making network operations more configurable, though. In fact, we would like to get rid of the external downloader, but can't because some people need specific settings that we don't, and never will, expose directly. So, if you, or anybody else, can come up with a more general solution that doesn't require us to add dozens of options to pacman.conf, we'd love to hear it.
I'm not sure how to getting rid of an external downloader would solve the problem. Giving people the option to tune download options ( or any options ) would always result in a larger configuration file no? At best, we could stick all the curl options together in a block in pacman.conf to improve readability. I'm of the opinion that exposing more curl options is great, as long as pacman.conf remains organized. Supporting every single option is of course silly, but I thought Connection timeout would benefit enough people since it saved me from having to wait over 2 minutes for pacman to finish an update. I guess in the end it's a compromise between maintainability, customizability, and user-friendliness. Nathan