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

Merge branch 'bw/push-submodule-only'

2017-01-31T21:14:56Z

"git submodule push" learned "--recurse-submodules=only option to push submodules out without pushing the top-level superproject. * bw/push-submodule-only: push: add option to push only submodules submodules: add RECURSE_SUBMODULES_ONLY value transport: reformat flag #defines to be more readable

Merge branch 'jc/push-default-explicit'

2016-12-27T08:11:40Z

A lazy "git push" without refspec did not internally use a fully specified refspec to perform 'current', 'simple', or 'upstream' push, causing unnecessary "ambiguous ref" errors. * jc/push-default-explicit: push: test pushing ambiguously named branches push: do not use potentially ambiguous default refspec

push: add option to push only submodules

2016-12-20T20:26:34Z

Teach push the --recurse-submodules=only option. This enables push to recursively push all unpushed submodules while leaving the superproject unpushed. This is a desirable feature in a scenario where updates to the superproject are handled automatically by some other means, perhaps a tool like Gerrit code review. In this scenario, a developer could make a change which spans multiple submodules and then push their commits for code review. Upon completion of the code review, their commits can be accepted and applied to their respective submodules while the code review tool can then automatically update the superproject to the most recent SHA1 of each submodule. This would reduce the merge conflicts in the superproject that could occur if multiple people are contributing to the same submodule. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

push: do not use potentially ambiguous default refspec

2016-10-29T06:30:30Z

When the user does the lazy "git push" with no parameters with push.default set to either "upstream", "simple" or "current", we internally generated a refspec that has the current branch name on the source side and used it to push. However, the branch name (say "test") may be an ambiguous refname in the context of the source repository---there may be a tag with the same name, for example. This would trigger an unnecessary error without any fault on the end-user's side. Be explicit and give a full refname as the source side to avoid the ambiguity. The destination side when pushing with the "current" sent only the name of the branch and forcing the receiving end to guess, which is the same issue. Be explicit there as well. Reported-by: Kannan Goundan Signed-off-by: Junio C Hamano

push: accept push options

2016-07-14T22:50:41Z

This implements everything that is required on the client side to make use of push options from the porcelain push command. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'mm/push-default-warning'

2016-02-26T21:37:25Z

Across the transition at around Git version 2.0, the user used to get a pretty loud warning when running "git push" without setting push.default configuration variable. We no longer warn, given that the transition is over long time ago. * mm/push-default-warning: push: remove "push.default is unset" warning message

push: remove "push.default is unset" warning message

2016-02-25T17:56:42Z

The warning was important before the 2.0 transition, and remained important for a while after, so that new users get push.default explicitly in their configuration and do not experience inconsistent behavior if they ever used an older version of Git. The warning has been there since version 1.8.0 (Oct 2012), hence we can expect the vast majority of current Git users to have been exposed to it, and most of them have already set push.default explicitly. The switch from 'matching' to 'simple' was planned for 2.0 (May 2014), but actually happened only for 2.3 (Feb 2015). Today, the warning is mostly seen by beginners, who have not set their push.default configuration (yet). For many of them, the warning is confusing because it talks about concepts that they have not learned and asks them a choice that they are not able to make yet. See for example http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0 (1260 votes for the question, 1824 for the answer as of writing) Remove the warning completely to avoid disturbing beginners. People who still occasionally use an older version of Git will be exposed to the warning through this old version. Eventually, versions of Git without the warning will be deployed enough and tutorials will not need to advise setting push.default anymore. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

Merge branch 'ew/force-ipv4'

2016-02-24T21:25:54Z

"git fetch" and friends that make network connections can now be told to only use ipv4 (or ipv6). * ew/force-ipv4: connect & http: support -4 and -6 switches for remote operations

connect & http: support -4 and -6 switches for remote operations

2016-02-12T19:34:14Z

Sometimes it is necessary to force IPv4-only or IPv6-only operation on networks where name lookups may return a non-routable address and stall remote operations. The ssh(1) command has an equivalent switches which we may pass when we run them. There may be old ssh(1) implementations out there which do not support these switches; they should report the appropriate error in that case. rsync support is untouched for now since it is deprecated and scheduled to be removed. Signed-off-by: Eric Wong Reviewed-by: Torsten Bögershausen Signed-off-by: Junio C Hamano

Merge branch 'ps/push-delete-option'

2016-01-12T23:16:54Z

"branch --delete" has "branch -d" but "push --delete" does not. * ps/push-delete-option: push: add '-d' as shorthand for '--delete' push: add '--delete' flag to synopsis