git/Documentation/git-push.txt, branch v2.16.2

builtin/push.c: add push.pushOption config

2017-10-24T00:57:54Z

Push options need to be given explicitly, via the command line as "git push --push-option

Merge branch 'ma/parse-maybe-bool'

2017-08-22T17:29:03Z

Code clean-up. * ma/parse-maybe-bool: parse_decoration_style: drop unused argument `var` treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool config: make git_{config,parse}_maybe_bool equivalent config: introduce git_parse_maybe_bool_text t5334: document that git push --signed=1 does not work Doc/git-{push,send-pack}: correct --sign= to --signed=

Doc/git-{push,send-pack}: correct --sign= to --signed=

2017-08-07T20:27:20Z

Since we're about to touch the behavior of --signed=, do this as a preparatory step. The documentation mentions --sign=, and it works. But that's just because it's an unambiguous abbreviation of --signed, which is how it is actually implemented. This was added in commit 30261094 ("push: support signing pushes iff the server supports it", 2015-08-19). Back when that series was developed [1] [2], there were suggestions about both --sign= and --signed=. The final implementation settled on --signed=, but some of the documentation and commit messages ended up using --sign=. The option is referred to as --signed= in Documentation/config.txt (under push.gpgSign). One could argue that we have promised --sign for two years now, so we should implement it as an alias for --signed. (Then we might also deprecate the latter, something which was considered already then.) That would be a slightly more intrusive change. This minor issue would only be a problem once we want to implement some other option --signfoo, but the earlier we do this step, the better. [1] v1-thread: https://public-inbox.org/git/1439492451-11233-1-git-send-email-dborowitz@google.com/T/#u [2] v2-thread: https://public-inbox.org/git/1439998007-28719-1-git-send-email-dborowitz@google.com/T/#m6533a6c4707a30b0d81e86169ff8559460cbf6eb Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

push: document & test --force-with-lease with multiple remotes

2017-04-20T01:53:06Z

Document & test for cases where there are two remotes pointing to the same URL, and a background fetch & subsequent `git push --force-with-lease` shouldn't clobber un-updated references we haven't fetched. Some editors like Microsoft's VSC have a feature to auto-fetch in the background, this bypasses the protections offered by --force-with-lease & --force-with-lease=, as noted in the documentation being added here. See the 'Tools that do an automatic fetch defeat "git push --force-with-lease"' (<1491617750.2149.10.camel@mattmccutchen.net>) git mailing list thread for more details. Jakub Narębski suggested this method of adding another remote to bypass this edge case, document that & add a test for it. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'bw/push-submodule-only'

2017-02-10T20:52:23Z

Add missing documentation update to a recent topic. * bw/push-submodule-only: completion: add completion for --recurse-submodules=only doc: add doc for git-push --recurse-submodules=only

doc: add doc for git-push --recurse-submodules=only

2017-02-01T23:16:49Z

Add documentation for the `--recurse-submodules=only` option of git-push. The feature was added in commit 225e8bf (add option to push only submodules). Signed-off-by: Cornelius Weig Signed-off-by: Junio C Hamano

Merge branch 'mm/push-social-engineering-attack-doc'

2017-01-10T23:24:24Z

Doc update on fetching and pushing. * mm/push-social-engineering-attack-doc: doc: mention transfer data leaks in more places

doc: mention transfer data leaks in more places

2016-11-14T19:23:07Z

The "SECURITY" section of the gitnamespaces(7) man page described two ways for a client to steal data from a server that wasn't intended to be shared. Similar attacks can be performed by a server on a client, so adapt the section to cover both directions and add it to the git-fetch(1), git-pull(1), and git-push(1) man pages. Also add references to this section from the documentation of server configuration options that attempt to control data leakage but may not be fully effective. Signed-off-by: Matt McCutchen Signed-off-by: Junio C Hamano

Merge branch 'jk/push-force-with-lease-creation'

2016-08-10T19:33:18Z

"git push --force-with-lease" already had enough logic to allow ensuring that such a push results in creation of a ref (i.e. the receiving end did not have another push from sideways that would be discarded by our force-pushing), but didn't expose this possibility to the users. It does so now. * jk/push-force-with-lease-creation: t5533: make it pass on case-sensitive filesystems push: allow pushing new branches with --force-with-lease push: add shorthand for --force-with-lease branch creation Documentation/git-push: fix placeholder formatting

Merge branch 'sb/push-options'

2016-08-03T22:10:24Z

"git push" learned to accept and pass extra options to the receiving end so that hooks can read and react to them. * sb/push-options: add a test for push options push: accept push options receive-pack: implement advertising and receiving push options push options: {pre,post}-receive hook learns about push options