On Monday 30 November 2015 at 10:31:26 -0800, Junio C Hamano wrote:
> Mike Crowe <mac@xxxxxxxxxx> writes:
>
> > diff --git a/builtin/push.c b/builtin/push.c
> > index 3bda430..dfced74 100644
> > --- a/builtin/push.c
> > +++ b/builtin/push.c
> > @@ -9,6 +9,7 @@
> > #include "transport.h"
> > #include "parse-options.h"
> > #include "submodule.h"
> > +#include "submodule-config.h"
> > #include "send-pack.h"
> >
> > static const char * const push_usage[] = {
> > @@ -20,7 +21,7 @@ static int thin = 1;
> > static int deleterefs;
> > static const char *receivepack;
> > static int verbosity;
> > -static int progress = -1;
> > +static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
>
> One variable per line, please. Especially when the two variables do
> not have anything to do with each other, and do not have any logical
> similarity between them.
I wouldn't normally have done that either, but I was mirroring the
equivalent code in fetch.c. I will change it.
> > @@ -452,22 +453,15 @@ static int do_push(const char *repo, int flags)
> > static int option_parse_recurse_submodules(const struct option *opt,
> > const char *arg, int unset)
> > {
> > - int *flags = opt->value;
> > + int *recurse_submodules = opt->value;
> >
> > - if (*flags & (TRANSPORT_RECURSE_SUBMODULES_CHECK |
> > - TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND))
> > + if (*recurse_submodules != RECURSE_SUBMODULES_DEFAULT)
> > die("%s can only be used once.", opt->long_name);
>
> The usual convention thoughout Git user experience is "the last one
> wins" (both in the configuration and in the command line options).
> Is there a good reason to deviate from that here?
I was aiming to retain the existing behaviour, which was to complain if
conflicting options were supplied on the command line. Making the last one
win would have been rather simpler. I can change this too, unless someone
knows why complaining about conflicting options would be useful.
Note that I previously sent an updated patch as
<1447758356-7727-1-git-send-email-mac@xxxxxxxxxx> but I believe that your
criticisms still apply.
Thanks for the review.
Mike.
--
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