git/builtin/push.c, branch v2.4.2

push: allow --follow-tags to be set by config push.followTags

2015-03-14T22:08:35Z

Signed-off-by: Dave Olszewski Helped-by: Jeff King Signed-off-by: Junio C Hamano

cmd_push: pass "flags" pointer to config callback

2015-02-17T18:49:29Z

This will let us manipulate any transport flags which have matching config options (there are none yet, but we will add one in the next patch). We could also just make "flags" a static file-scope global, but the result is a little confusing. We end up passing it along through do_push and push_with_options, each of which further munge it. Having slightly-differing versions of the flags variable available to those functions would probably cause more confusion than it is worth. Let's just keep the original local to cmd_push, and it can continue to pass it through the call-stack. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

cmd_push: set "atomic" bit directly

2015-02-17T18:49:18Z

This makes the code shorter and more obvious by removing an unnecessary interim variable. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

git_push_config: drop cargo-culted wt_status pointer

2015-02-16T06:55:11Z

The push config callback does not expect any incoming data via the void pointer. And if it did, it would certainly not be a "struct wt_status". This probably got picked up accidentally in b945901 (push: heed user.signingkey for signed pushes, 2014-10-22), which copied the template for the config callback from builtin/commit.c. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'sb/atomic-push'

2015-02-11T21:43:51Z

"git push" has been taught a "--atomic" option that makes push to update more than one ref an "all-or-none" affair. * sb/atomic-push: Document receive.advertiseatomic t5543-atomic-push.sh: add basic tests for atomic pushes push.c: add an --atomic argument send-pack.c: add --atomic command line argument send-pack: rename ref_update_to_be_sent to check_to_send_update receive-pack.c: negotiate atomic push support receive-pack.c: add execute_commands_atomic function receive-pack.c: move transaction handling in a central place receive-pack.c: move iterating over all commands outside execute_commands receive-pack.c: die instead of error in case of possible future bug receive-pack.c: shorten the execute_commands loop over all commands

push.c: add an --atomic argument

2015-01-08T03:56:44Z

Add a command line argument to the git push command to request atomic pushes. Signed-off-by: Ronnie Sahlberg Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'jk/push-simple'

2014-12-12T22:31:40Z

Git 2.0 was supposed to make the "simple" mode for the default of "git push", but it didn't. * jk/push-simple: push: truly use "simple" as default, not "upstream"

Merge branch 'rt/push-recurse-submodule-usage-string'

2014-12-12T22:31:38Z

* rt/push-recurse-submodule-usage-string: builtin/push.c: fix description of --recurse-submodules option

push: truly use "simple" as default, not "upstream"

2014-12-01T02:11:25Z

The plan for the push.default transition had all along been to use the "simple" method rather than "upstream" as a default if the user did not specify their own push.default value. Commit 11037ee (push: switch default from "matching" to "simple", 2013-01-04) tried to implement that by moving PUSH_DEFAULT_UNSPECIFIED in our switch statement to fall-through to the PUSH_DEFAULT_SIMPLE case. When the commit that became 11037ee was originally written, that would have been enough. We would fall through to calling setup_push_upstream() with the "simple" parameter set to 1. However, it was delayed for a while until we were ready to make the transition in Git 2.0. And in the meantime, commit ed2b182 (push: change `simple` to accommodate triangular workflows, 2013-06-19) threw a monkey wrench into the works. That commit drops the "simple" parameter to setup_push_upstream, and instead checks whether the global "push_default" is PUSH_DEFAULT_SIMPLE. This is right when the user has explicitly configured push.default to simple, but wrong when we are a fall-through for the "unspecified" case. We never noticed because our push.default tests do not cover the case of the variable being totally unset; they only check the "simple" behavior itself. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

builtin/push.c: fix description of --recurse-submodules option

2014-11-18T19:19:16Z

The description of the option for argument "recurse-submodules" is marked for translation even if it expects the untranslated string and it's missing the option "on-demand" which was introduced in eb21c73 (2014-03-29, push: teach --recurse-submodules the on-demand option). Fix this by unmark the string for translation and add the missing option. Signed-off-by: Ralf Thielow Signed-off-by: Junio C Hamano