# [PATCH 28/28] makes upload_pack void 4 messages from 2006-08-14 to 2006-08-14. Participants: David Rientjes, Nikolai Weibull. Thread: https://gitlist.dev/t/5277 ## David Rientjes, 2006-08-14 20:40 Subject: [PATCH 28/28] makes upload_pack void Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0608141340060.19383%40chino.corp.google.com ``` Makes upload_pack void and removes conditional return. David Signed-off-by: David Rientjes --- upload-pack.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index bbd6bd6..27e2abe 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -459,18 +459,17 @@ static int send_ref(const char *refname, return 0; } -static int upload_pack(void) +static void upload_pack(void) { reset_timeout(); head_ref(send_ref); for_each_ref(send_ref); packet_flush(1); receive_needs(); - if (!want_obj.nr) - return 0; - get_common_commits(); - create_pack_file(); - return 0; + if (want_obj.nr) { + get_common_commits(); + create_pack_file(); + } } int main(int argc, char **argv) -- 1.4.2.g89bb-dirty ``` ## Nikolai Weibull, 2006-08-14 22:45 Subject: Re: [PATCH 28/28] makes upload_pack void Message-ID: URL: https://gitlist.dev/e/dbfc82860608141545s3e75457eo4be1201395e24354%40mail.gmail.com In-Reply-To: ``` On 8/14/06, David Rientjes wrote: > Makes upload_pack void and removes conditional return. > -static int upload_pack(void) > +static void upload_pack(void) I don't know for sure, but I'm guessing the intention was to be able to return a failing code /if/ there ever was a condition where upload_pack() would fail, e.g., if send_ref() would return a status code instead of die():ing if it can't parse the given sha1. In a future libification, the change of return type may have to be reverted. nikolai ``` ## David Rientjes, 2006-08-14 22:51 Subject: Re: [PATCH 28/28] makes upload_pack void Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0608141549150.21515%40chino.corp.google.com In-Reply-To: ``` On Tue, 15 Aug 2006, Nikolai Weibull wrote: > I don't know for sure, but I'm guessing the intention was to be able > to return a failing code /if/ there ever was a condition where > upload_pack() would fail, e.g., if send_ref() would return a status > code instead of die():ing if it can't parse the given sha1. In a > future libification, the change of return type may have to be > reverted. > Of course. If upload_pack were modified to return an error code based on a specific code path, I trust the implementer would know how to change void to int. David ``` ## Nikolai Weibull, 2006-08-14 23:03 Subject: Re: [PATCH 28/28] makes upload_pack void Message-ID: URL: https://gitlist.dev/e/dbfc82860608141603y64737257n85cc169a6f58ff7e%40mail.gmail.com In-Reply-To: ``` On 8/15/06, David Rientjes wrote: > On Tue, 15 Aug 2006, Nikolai Weibull wrote: > > I don't know for sure, but I'm guessing the intention was to be able > > to return a failing code /if/ there ever was a condition where > > upload_pack() would fail, e.g., if send_ref() would return a status > > code instead of die():ing if it can't parse the given sha1. In a > > future libification, the change of return type may have to be > > reverted. > Of course. > > If upload_pack were modified to return an error code based on a specific code > path, I trust the implementer would know how to change void to int. So do I. However, I trust that whoever implemented send_ref() knew about void. (See how easy it was to do what you did but the other way around?) It was just a comment. I don't have anything against the patch as such. nikolai ```