Jeff King <p...@peff.net> writes:

> From: Dave Olszewski <cx...@pobox.com>
>
> Signed-off-by: Dave Olszewski <cx...@pobox.com>
> ---
> Again, this is just a preview. Dave should send the final when he thinks
> it is good.

Dave?

I do not see anything wrong with this version that builds on top of
the previous 2 clean-up.  Personally I find that these clean-up
changes more valuable than I care about this particular feature, and
it is unfortunate that waiting an Ack or reroll of this one kept
them stalled.

I am tempted to throw "Helped-by: Peff" into the log message and
merge the result to 'next', unless I hear otherwise in a few days.

> The if/else I added to the config callback is kind of ugly. I wonder if
> we should have git_config_bit, or even just a function to set/clear a
> bit. Then the OPT_BIT code could use it, too. Something like:
>
>   munge_bit(flags, TRANSPORT_PUSH_FOLLOW_TAGS, git_config_bool(k, v));
>
> Or maybe that is getting too fancy and obfuscated for a simple bit
> set/clear. I dunno.

I think we agreed that the code we have in this series is good.

>  Documentation/config.txt               | 6 ++++++
>  Documentation/git-push.txt             | 5 ++++-
>  builtin/push.c                         | 9 +++++++++
>  contrib/completion/git-completion.bash | 1 +
>  4 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ae6791d..e01d21c 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2079,6 +2079,12 @@ new default).
>  
>  --
>  
> +push.followTags::
> +     If set to true enable '--follow-tags' option by default.  You
> +     may override this configuration at time of push by specifying
> +     '--no-follow-tags'.
> +
> +
>  rebase.stat::
>       Whether to show a diffstat of what changed upstream since the last
>       rebase. False by default.
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index ea97576..caa187b 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -128,7 +128,10 @@ already exists on the remote side.
>       Push all the refs that would be pushed without this option,
>       and also push annotated tags in `refs/tags` that are missing
>       from the remote but are pointing at commit-ish that are
> -     reachable from the refs being pushed.
> +     reachable from the refs being pushed.  This can also be specified
> +     with configuration variable 'push.followTags'.  For more
> +     information, see 'push.followTags' in linkgit:git-config[1].
> +
>  
>  --signed::
>       GPG-sign the push request to update refs on the receiving
> diff --git a/builtin/push.c b/builtin/push.c
> index c25108f..6831c2d 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -482,6 +482,7 @@ static int option_parse_recurse_submodules(const struct 
> option *opt,
>  
>  static int git_push_config(const char *k, const char *v, void *cb)
>  {
> +     int *flags = cb;
>       int status;
>  
>       status = git_gpg_config(k, v, NULL);
> @@ -511,6 +512,14 @@ static int git_push_config(const char *k, const char *v, 
> void *cb)
>               return 0;
>       }
>  
> +     if (!strcmp(k, "push.followtags")) {
> +             if (git_config_bool(k, v))
> +                     *flags |= TRANSPORT_PUSH_FOLLOW_TAGS;
> +             else
> +                     *flags &= ~TRANSPORT_PUSH_FOLLOW_TAGS;
> +             return 0;
> +     }
> +
>       return git_default_config(k, v, NULL);
>  }
>  
> diff --git a/contrib/completion/git-completion.bash 
> b/contrib/completion/git-completion.bash
> index c21190d..cffb2b8 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2188,6 +2188,7 @@ _git_config ()
>               pull.octopus
>               pull.twohead
>               push.default
> +             push.followTags
>               rebase.autosquash
>               rebase.stat
>               receive.autogc
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to