Re: [PATCH 2/4] remote.c: introduce a way to have different remotes for fetch/ push

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King wrote:
> On Mon, Mar 18, 2013 at 06:46:13PM +0530, Ramkumar Ramachandra wrote:
>
>> +struct remote *remote_get(const char *name)
>> +{
>> +     int name_given = 0;
>> +
>> +     read_config();
>> +     if (name)
>> +             name_given = 1;
>> +     else {
>> +             name = default_remote_name;
>> +             name_given = explicit_default_remote_name;
>> +     }
>> +     return remote_get_1(name, name_given);
>> +}
>> +
>> +struct remote *pushremote_get(const char *name)
>> +{
>> +     int name_given = 0;
>> +
>> +     read_config();
>> +     if (name)
>> +             name_given = 1;
>> +     else {
>> +             if (pushremote_name) {
>> +                     name = pushremote_name;
>> +                     name_given = 1;
>> +             } else {
>> +                     name = default_remote_name;
>> +                     name_given = explicit_default_remote_name;
>> +             }
>> +     }
>> +     return remote_get_1(name, name_given);
>> +}
>
> Can we get rid of this duplication by having remote_get_1 take a
> service-specific default argument? And then each service calls it like:
>
>   struct remote *remote_get(const char *name)
>   {
>           read_config();
>           return remote_get_1(name, NULL);
>   }
>
>   struct remote *pushremote_get(const char *name)
>   {
>           read_config();
>           return remote_get_1(name, pushremote_name);
>   }

Thanks for the dose of sanity.  While at it, why not move
read_config() to remote_get_1() as well?
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]