{"thread":{"id":"30846","subject":"What's cooking in git.git (Jun 2012, #05; Tue, 19)","startedAt":"2012-06-19T23:46:44Z","lastAt":"2012-06-24T11:01:37Z","messageCount":15,"participants":["Junio C Hamano","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"193911","messageId":"7vbokeyie3.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":null,"subject":"What's cooking in git.git (Jun 2012, #05; Tue, 19)","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2012-06-19T23:46:44Z","receivedAt":"2012-06-19T23:46:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.\n\nNow 1.7.11 is out, I'll start merging topics that have been cooking\nin 'next' to 'master', but let's wait for a few days in case some\nbrown paper bag bugfixes are needed.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[New Topics]\n\n* cn/cherry-pick-range-docs (2012-06-15) 2 commits\n - git-cherry-pick.txt: clarify the use of revision range notation\n - Documentation: --no-walk is no-op if range is specified\n\nWill merge to 'next' and soon to 'master'.\n\n* jc/sha1-name-more (2012-06-18) 9 commits\n - sha1_name.c: get_describe_name() by definition groks only commits\n - sha1_name.c: teach get_short_sha1() a commit-only option\n - sha1_name.c: allow get_short_sha1() to take other flags\n - sha1_name.c: teach find_short_packed_object() a commit-only option\n - sha1_name.c: teach find_short_object_filename() a commit-only option\n - sha1_name.c: refactor find_short_packed_object()\n - sha1_name.c: rename \"now\" to \"current\"\n - sha1_name.c: clarify what \"fake\" is for in find_short_object_filename()\n - sha1_name.c: indentation fix\n\nTeaches the object name parser that a \"git describe\" output is\nalways a commit object, to prolong the lifetime of abbreviated\nobject name in it.\n\n* jk/version-string-dependency (2012-06-19) 3 commits\n - Makefile: split prefix flags from GIT-CFLAGS\n - Makefile: split GIT_USER_AGENT from GIT-CFLAGS\n - Makefile: apply dependencies consistently to sparse/asm targets\n (this branch uses jk/version-string.)\n\n* jn/perl-makemaker-leading-paths (2012-06-15) 1 commit\n - perl/Makefile: move \"mkdir -p\" to module installation loop for maintainability\n\nWill wait for a few days to see if somebody comes up with a more\nconcise and cleaner way to do this, but otherwise this looked good.\n\n* mm/verify-filename-fix (2012-06-18) 2 commits\n - verify_filename(): ask the caller to chose the kind of diagnosis\n - sha1_name: do not trigger detailed diagnosis for file arguments\n\n\"git diff COPYING HEAD:COPYING\" gave a nonsense error message that\nclaimed that the treeish HEAD did not have COPYING in it.\n\nWill merge to 'next' and soon to 'master'.\n\n* tr/maint-show-walk (2012-06-19) 2 commits\n - show: fix \"range implies walking\"\n - Demonstrate git-show is broken with ranges\n\nFixes \"git show\"'s auto-walking behaviour, and make it behave just\nlike \"git log\" does when it walks.\n\nNote that this is different from Thomas's patch.\n\n--------------------------------------------------\n[Stalled]\n\n* db/vcs-svn (2012-06-01) 6 commits\n - vcs-svn: drop no-op reset methods\n - vcs-svn: fix signedness warnings\n - vcs-svn: prefer strstr over memmem\n - vcs-svn: prefer constcmp to prefixcmp\n - vcs-svn: simplify cleanup in apply_one_window()\n - vcs-svn: fix clang-analyzer error\n\nWaiting for Jonathan's clean-up offered earlier.\n\n* vr/use-our-perl-in-tests (2012-06-12) 3 commits\n - t/README: add a bit more Don'ts\n - tests: enclose $PERL_PATH in duoble quotes\n - t: Replace 'perl' by $PERL_PATH\n\nNeeds more work.\n\nThere are still unconverted use of bare 'perl' remaining in the test\nscripts, the second patch needs its title typofixed, and PERL_PATH\nneeds to be exported to the environment from test-lib.sh.\n\n* jc/apply-3way (2012-06-13) 19 commits\n - apply --3way: tests\n - apply: document --3way option\n - apply: allow rerere() upon --3way results\n - apply: register conflicted stages to the index\n - apply: --3way with add/add conflict\n - apply: move verify_index_match() higher\n - apply: plug the three-way merge logic in\n - apply: fall back on three-way merge\n - apply: accept -3/--3way command line option\n - apply: move \"already exists\" logic to check_to_create()\n - apply: move check_to_create_blob() closer to its sole caller\n - apply: further split load_preimage()\n - apply: refactor \"previous patch\" logic\n - apply: split load_preimage() helper function out\n - apply: factor out checkout_target() helper function\n - apply: refactor read_file_or_gitlink()\n - apply: clear_image() clears things a bit more\n - apply: a bit more comments on PATH_TO_BE_DELETED\n - apply: fix an incomplete comment in check_patch()\n\n\"git apply\" learns to wiggle the base version and perform three-way merge\nwhen a patch does not exactly apply to the version you have.\n\nWaiting for comments.\n\n* nl/http-proxy-more (2012-05-11) 2 commits\n - http: rename HTTP_REAUTH to HTTP_AUTH_RETRY\n - http: Avoid limit of retrying request only twice\n\nI queued only the later two patches from this series, even though they do\nnot make much sense without the first one that seems to need a bit more\nwork, so that we won't forget.\n\nWill discard without prejudice, unless rerolled.\n\n* jk/no-op-push-message (2012-05-30) 1 commit\n - improve no-op push output\n\nRewords the status message of \"git push\" that pushed only one ref\ndifferently from \"Everything up-to-date\", to give a bit more help to\npeople who get the message when their current branch is not pushed.\n\nI had an impression after the discussion thread that a redesign is\ncoming, but it hasn't happened yet.\n\nWill discard without prejudice, unless rerolled.\n\n* sg/bash-prompt (2012-05-09) 4 commits\n . completion: respect $GIT_DIR\n . completion: use __gitdir() in _git_log()\n - tests: add tests for the bash prompt functions in the completion script\n - tests: move code to run tests under bash into a helper library\n (this branch is tangled with fc/git-prompt-script.)\n\nThis is only the \"correction\" bits taken from the beginning of a\nlarger series that is to be rerolled.  The tip commit has been\ncherry-picked to fc/fc/git-prompt-script topic.\n\nWill discard without prejudice.\n\n* jc/maint-push-refs-all (2012-05-04) 2 commits\n - get_fetch_map(): tighten checks on dest refs\n - fetch/push: allow refs/*:refs/*\n\nAllows pushing and fetching refs/stash.\nThere still seem to be other bugs hiding (e.g. try pushing twice).\n\nNot ready.\n\n* jc/run-hook-env-1 (2012-03-11) 1 commit\n . run_hook(): enhance the interface to pass arbitrary environment\n\nUpdates run_hook() API to be much less specific to \"commit\".  It would\nonly be useful if people start doing more interesting things with hooks.\n\nWill discard.\n\n* jc/split-blob (2012-04-03) 6 commits\n - chunked-object: streaming checkout\n - chunked-object: fallback checkout codepaths\n - bulk-checkin: support chunked-object encoding\n - bulk-checkin: allow the same data to be multiply hashed\n - new representation types in the packstream\n - packfile: use varint functions\n\nNot ready.\n\nI finished the streaming checkout codepath, but as explained in\n127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),\nthese are still early steps of a long and painful journey. At least\npack-objects and fsck need to learn the new encoding for the series\nto be usable locally, and then index-pack/unpack-objects needs to\nlearn it to be used remotely.\n\nGiven that I heard a lot of noise that people want large files, and\nthat I was asked by somebody at GitTogether'11 privately for an\nadvice on how to pay developers (not me) to help adding necessary\nsupport, I am somewhat dissapointed that the original patch series\nthat was sent almost two months ago still remains here without much\ncomments and updates from the developer community. I even made the\ninterface to the logic that decides where to split chunks easily\nreplaceable, and I deliberately made the logic in the original patch\nextremely stupid to entice others, especially the \"bup\" fanboys, to\ncome up with a better logic, thinking that giving people an easy\ntarget to shoot for, they may be encouraged to help out. The plan is\nnot working :-(.\n\n--------------------------------------------------\n[Cooking]\n\n* fc/git-prompt-script (2012-06-19) 7 commits\n - completion: respect $GIT_DIR\n - completion: warn people about duplicated function\n - completion: split __git_ps1 into a separate script\n - completion: remove executable mode\n - Merge branch 'fc/git-complete-helper' into fc/git-prompt-script\n - tests: add tests for the bash prompt functions in the completion script\n - tests: move code to run tests under bash into a helper library\n (this branch is tangled with sg/bash-prompt.)\n\nSplits a rather heavy-ish \"git completion\" script out and creates a\nseparate \"git prompting\" script, to help lazy-autoloading of the\ncompletion part while making prompting part always available.\n\nWill merge to 'next'.\n\n* lm/git-blame-el (2012-06-14) 3 commits\n - git-blame.el: Do not use bare 0 to mean (point-min)\n - git-blame.el: Use with-current-buffer where appropriate\n - git-blame.el: Do not use goto-line in lisp code\n\nWill merge to 'next' and soon to 'master'.\n\n* lp/no-cmd-http-fetch (2012-06-15) 1 commit\n - builtin.h: remove unused cmd_<foo> declarations\n\nWill merge to 'next' and soon to 'master'.\n\n* jk/diff-no-index-pager (2012-06-15) 2 commits\n - do not run pager with diff --no-index --quiet\n - fix pager.diff with diff --no-index\n\nWill merge to 'next' and soon to 'master'.\n\n* nd/i18n-branch-lego (2012-06-07) 1 commit\n - Remove i18n legos in notifying new branch tracking setup\n\nRestructure the way message strings are created, in preparation for\nmarking them for i18n.\n\nWill merge to 'next' and soon to 'master'.\n\n* nd/i18n-misc (2012-06-07) 3 commits\n - rerere: remove i18n legos in result message\n - notes-merge: remove i18n legos in merge result message\n - reflog: remove i18n legos in pruning message\n\nRestructure the way message strings are created, in preparation for\nmarking them for i18n.\n\nWill merge to 'next' and soon to 'master'.\n\n* rr/doc-commit (2012-06-08) 1 commit\n - commit: document a couple of options\n\nWill merge to 'next' and soon to 'master'.\n\n* hv/remote-end-hung-up (2012-06-19) 1 commit\n - remove the impression of unexpectedness when access is denied\n\nWill merge to 'next'.\n\n* hv/submodule-checkout-nuke-submodules (2012-06-11) 1 commit\n - update-index: allow overwriting existing submodule index entries\n\nWill merge to 'next'.\n\n* jc/rev-list-simplify-merges-first-parent (2012-06-13) 3 commits\n - revision: ignore side parents while running simplify-merges\n - revision: note the lack of free() in simplify_merges()\n - revision: \"simplify\" options imply topo-order sort\n\nI need to send this out to the list for re-review.\n\n* jc/ustar-checksum-is-unsigned (2012-06-13) 1 commit\n - archive: ustar header checksum is computed unsigned\n\nWill merge to 'next' and soon to 'master'.\n\n* rs/git-blame-mapcar-mapc (2012-06-10) 1 commit\n - git-blame.el: use mapc instead of mapcar\n\nWill merge to 'next' and soon to 'master'.\n\n* rs/ipv6-ssh-url (2012-06-13) 1 commit\n - git: Wrong parsing of ssh urls with IPv6 literals ignores port\n\nWill merge to 'next' and soon to 'master'.\n\n* nd/exclude-workaround-top-heavy (2012-06-07) 3 commits\n - exclude: do strcmp as much as possible before fnmatch\n - dir.c: get rid of the wildcard symbol set in no_wildcard()\n - Unindent excluded_from_list()\n\nAttempts to optimize matching with an exclude pattern with a deep\ndirectory hierarchy by taking the part that specifies leading path\nwithout wildcard literally.\n\nWill merge to 'next'.\n\n* jc/bundle-complete-notice (2012-06-04) 1 commit\n  (merged to 'next' on 2012-06-19 at b42227b)\n + tweak \"bundle verify\" of a complete history\n\nOriginally merged to 'next' on 2012-06-04.\n\nRunning \"git bundle verify\" on a bundle that records a complete\nhistory said \"it requires these 0 commits\".\n\nWill merge to 'master'.\n\n* lk/more-helpful-status-hints (2012-06-14) 4 commits\n - status: better advices when splitting a commit (during rebase -i)\n - status: don't suggest \"git rm\" or \"git add\" if not appropriate\n - t7512-status-help.sh: better advices for git status\n - wt-status.*: better advices for git status added\n\nWill merge to 'next'.\n\n* jk/no-more-pre-exec-callback (2012-06-05) 1 commit\n - pager: drop \"wait for output to run less\" hack\n\nOn hold for 6 months until ancient \"less\" goes extinct.\n\n* jk/maint-t1304-setfacl (2012-06-07) 1 commit\n  (merged to 'next' on 2012-06-19 at 2449521)\n + t1304: improve setfacl prerequisite setup\n\nOriginally merged to 'next' on 2012-06-08.\n\nWorks around a false test failure caused by a bug in ecryptofs.\n\nWill merge to 'master'.\n\n* lk/rebase-i-x (2012-06-13) 1 commit\n - rebase -i: teach \"--exec <cmd>\"\n\nAdds -x <cmd> to \"rebase -i\" to insert \"exec <cmd>\" after each\ncommit in the resulting history.\n\nWill merge to 'next'.\n\n* vr/help-per-platform (2012-06-06) 1 commit\n  (merged to 'next' on 2012-06-19 at d9a08ba)\n + help: use HTML as the default help format on Windows\n\nOriginally merged to 'next' on 2012-06-08\n\nWe used to always default to \"man\" format even on platforms where\n\"man\" viewer is not widely available.\n\nWill merge to 'master'.\n\n* jc/ls-files-i-dir (2012-06-05) 6 commits\n  (merged to 'next' on 2012-06-19 at 4a7aa99)\n + dir.c: make excluded() file scope static\n + unpack-trees.c: use path_excluded() in check_ok_to_remove()\n + builtin/add.c: use path_excluded()\n + path_excluded(): update API to less cache-entry centric\n + ls-files -i: micro-optimize path_excluded()\n + ls-files -i: pay attention to exclusion of leading paths\n\nOriginally merged to 'next' on 2012-06-08.\n\n\"git ls-files --exclude=t -i\" did not consider anything under t/\nas excluded, as it did not pay attention to exclusion of leading\npaths while walking the index.  Other two users of excluded() are\nalso updated.\n\nWill merge to 'master'.\n\n* jc/request-pull-match-tagname (2012-06-01) 1 commit\n  (merged to 'next' on 2012-06-19 at bb96d6c)\n + request-pull: really favor a matching tag\n\nOriginally merged to 'next' on 2012-06-05.\n\n\"git request-pull $url dev\" when the tip of \"dev\" branch was tagged\nwith \"ext4-for-linus\" used the contents from the tag in the output\nbut still asked the \"dev\" branch to be pulled, not the tag.\n\nWill merge to 'master'.\n\n* jk/version-string (2012-06-03) 3 commits\n  (merged to 'next' on 2012-06-19 at 12f8e07)\n + http: get default user-agent from git_user_agent\n + version: add git_user_agent function\n + move git_version_string into version.c\n (this branch is used by jk/version-string-dependency.)\n\nOriginally merged to 'next' on 2012-06-05.\n\nTeaches git native protocol agents to show software version over the\nwire.\n\nWill merge to 'master'.\n\n* nd/stream-pack-objects (2012-05-29) 1 commit\n - pack-objects: use streaming interface for reading large loose blobs\n\nWill merge to 'next'.\n\n* jk/clone-local (2012-05-30) 2 commits\n  (merged to 'next' on 2012-06-19 at a42bbcc)\n + clone: allow --no-local to turn off local optimizations\n + docs/clone: mention that --local may be ignored\n\nOriginally merged to 'next' on 2012-06-05.\n\n\"git clone --local $path\" started its life as an experiment to\noptionally use link/copy when cloning a repository on the disk, but\nwe didn't deprecate it after we made the option a no-op to always\nuse the optimization.\n\nWill merge to 'master'.\n\n* jk/no-more-asciidoc7 (2012-05-30) 2 commits\n  (merged to 'next' on 2012-06-19 at a36b498)\n + docs: drop antique comment from Makefile\n + docs: drop asciidoc7compatible flag\n\nOriginally merged to 'next' on 2012-06-05.\n\nWe no longer use AsciiDoc7 syntax in our documentation and favor a\nmore modern style.\n\nWill merge to 'master'.\n\n* nd/stream-index-pack (2012-05-24) 4 commits\n - index-pack: use streaming interface for collision test on large blobs\n - index-pack: factor out unpack core from get_data_from_pack\n - index-pack: use streaming interface on large blobs (most of the time)\n - index-pack: hash non-delta objects while reading from stream\n\nUse streaming API to read from the object store to avoid having to hold\na large blob object in-core while running index-pack.\n\nWill merge to 'next'.\n\n* js/submodule-relative (2012-06-14) 5 commits\n - t7400: avoid path mangling issues\n - submodule: fix handling of superproject origin URLs like foo, ./foo and ./foo/bar\n - submodule: fix sync handling of some relative superproject origin URLs\n - submodule: document failure to handle relative superproject origin URLs\n - submodule: additional regression tests for relative URLs\n\nMakes \"git submodule\" deal with nested submodule structure where a\nmodule is contained within a module whose origin is specified as a\nrelative URL to its superproject's origin.\n\nWill merge to 'next'.\n\n* mm/push-default-switch-warning (2012-06-06) 1 commit\n - push: start warning upcoming default change for push.default\n\nWill merge to 'next'.\n\nHopwefully we can have a solidly tested series early in 1.7.12 or\n1.7.13 at the latest.\n\n--------------------------------------------------\n[Discarded]\n\n* cb/daemon-test-race-fix (2012-04-27) 2 commits\n  (merged to 'next' on 2012-04-27 at 84bbcf8)\n + Revert \"git-daemon wrapper to wait until daemon is ready\"\n  (merged to 'next' on 2012-04-24 at d5c30be)\n + git-daemon wrapper to wait until daemon is ready\n\nReverted from 'next' to replace it with js/daemon-test-race-fix.\n\n* jc/merge-annotated-tag (2012-06-05) 2 commits\n . merge: allow fast-forwarding to an annotated but unsigned tag\n . merge: separte the logic to check for a signed tag\n\n\"git merge anno\" created a merge commit even when anno is an\nunsigned annotated tag that points at a commit that can be fast\nforwarded to; this came from a laziness of the implementation of\nmerging of signed tags in 1.7.9.  People may have different opinion\non making signed and unsigned annotated tag behave differently, but\nI tend to agree that it is probably not a good idea.\n"},{"id":"193930","messageId":"1340195750-846-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"30846","inReplyTo":"7vbokeyie3.fsf@alter.siamese.dyndns.org","subject":"[PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-06-20T12:35:50Z","receivedAt":"2012-06-20T12:35:50Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"In preparation for flipping the default to the \"simple\" mode from\nthe \"matching\" mode that is the historical default, start warning\nusers when they rely on unconfigured \"git push\" to default to the\n\"matching\" mode.\n\nAlso, advertise for 'simple' where 'current' and 'upstream' are advised.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n> * mm/push-default-switch-warning (2012-06-06) 1 commit\n>  - push: start warning upcoming default change for push.default\n> \n> Will merge to 'next'.\n> \n> Hopwefully we can have a solidly tested series early in 1.7.12 or\n> 1.7.13 at the latest.\n\nI've made a slightly modified version of the patch which adds these\ntwo lines:\n\n+   \"(the 'simple' mode was introduced in Git 1.7.11. Use 'current' instead if\\n\"\n+   \"you sometimes use older versions of Git)\");\n\nI actually had problems setting \"push.default=upstream\" on a\nNFS-shared $HOME, where one machine was running a brand new Git, and\nanother the old version from Debian stable, who didn't know about the\nupstream mode. The old machine started refusing pushes because of\nthis :-(.\n\n'current' has existed for years (while upstream has been called\n'tracking' before), so it makes more sense to advertise this one for\npeople occasionally using old versions of Git.\n\n builtin/push.c       | 29 +++++++++++++++++++++++++++--\n t/t5541-http-push.sh |  5 ++++-\n 2 files changed, 31 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 08ccb89..2eba331 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -147,12 +147,37 @@ static void setup_push_upstream(struct remote *remote, int simple)\n \tadd_refspec(refspec.buf);\n }\n \n+static char warn_unspecified_push_default_msg[] =\n+N_(\"push.default is unset; its implicit value is changing in\\n\"\n+   \"Git 2.0 from 'matching' to 'simple'. To squelch this message\\n\"\n+   \"and maintain the current behavior after the default changes, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default matching\\n\"\n+   \"\\n\"\n+   \"To squelch this message and adopt the new behavior now, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default simple\\n\"\n+   \"\\n\"\n+   \"See 'git help config' and search for 'push.default' for further information.\\n\"\n+   \"(the 'simple' mode was introduced in Git 1.7.11. Use 'current' instead if\\n\"\n+   \"you sometimes use older versions of Git)\");\n+\n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(\"%s\\n\", _(warn_unspecified_push_default_msg));\n+}\n+\n static void setup_default_push_refspecs(struct remote *remote)\n {\n \tswitch (push_default) {\n \tdefault:\n \tcase PUSH_DEFAULT_UNSPECIFIED:\n \t\tdefault_matching_used = 1;\n+\t\twarn_unspecified_push_default_configuration();\n \t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n@@ -186,8 +211,8 @@ static const char message_advice_pull_before_push[] =\n static const char message_advice_use_upstream[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\n \t   \"counterpart. If you did not intend to push that branch, you may want to\\n\"\n-\t   \"specify branches to push or set the 'push.default' configuration\\n\"\n-\t   \"variable to 'current' or 'upstream' to push only the current branch.\");\n+\t   \"specify branches to push or set the 'push.default' configuration variable\\n\"\n+\t   \"to 'simple', 'current' or 'upstream' to push only the current branch.\");\n \n static const char message_advice_checkout_pull_push[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\ndiff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh\nindex 5b170be..07fa199 100755\n--- a/t/t5541-http-push.sh\n+++ b/t/t5541-http-push.sh\n@@ -64,7 +64,10 @@ test_expect_success 'no empty path components' '\n \n test_expect_success 'clone remote repository' '\n \trm -rf test_repo_clone &&\n-\tgit clone $HTTPD_URL/smart/test_repo.git test_repo_clone\n+\tgit clone $HTTPD_URL/smart/test_repo.git test_repo_clone &&\n+\t(\n+\t\tcd test_repo_clone && git config push.default matching\n+\t)\n '\n \n test_expect_success 'push to remote repository (standard)' '\n-- \n1.7.11.rc3.235.gd0d1d08\n"},{"id":"193944","messageId":"7vehp9x3yz.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":"1340195750-846-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-20T17:55:48Z","receivedAt":"2012-06-20T17:55:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> In preparation for flipping the default to the \"simple\" mode from\n> the \"matching\" mode that is the historical default, start warning\n> users when they rely on unconfigured \"git push\" to default to the\n> \"matching\" mode.\n>\n> Also, advertise for 'simple' where 'current' and 'upstream' are advised.\n>\n> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n>> * mm/push-default-switch-warning (2012-06-06) 1 commit\n>>  - push: start warning upcoming default change for push.default\n>> \n>> Will merge to 'next'.\n>> \n>> Hopwefully we can have a solidly tested series early in 1.7.12 or\n>> 1.7.13 at the latest.\n>\n> I've made a slightly modified version of the patch which adds these\n> two lines:\n>\n> +   \"(the 'simple' mode was introduced in Git 1.7.11. Use 'current' instead if\\n\"\n> +   \"you sometimes use older versions of Git)\");\n\nI am not sure who this wants to help.  For people who want to\nanticipate the future, using anything but 'simple' is not living in\nthe future and waiting for an additional pain coming from the\ndifferences between current and simple.  If current and simple are\nsimilar enough that their differences do not matter, why wait for\nsimple to be available everywhere and switch the default to it,\ninstead of using current as the default in the first place?\n\nSo if anything, I'd prefer the above message without \"Use 'current'\ninstead\" bit.\n"},{"id":"193949","messageId":"vpqpq8t96zw.fsf@bauges.imag.fr","threadId":"30846","inReplyTo":"7vehp9x3yz.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-06-20T18:24:19Z","receivedAt":"2012-06-20T18:24:19Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I am not sure who this wants to help.\n\nThe target is for people who may use different versions of Git (e.g.\nseveral installed git on the same machine, several machine, or worse,\nseveral machines with a shared $HOME/.gitconfig). This includes me.\n\nFor these people, setting push.default=simple is basically impossible\nsince Git errors out when encountering such setting (it's not ignored,\nit really makes Git die).\n\n> For people who want to anticipate the future, using anything but\n> 'simple' is not living in the future and waiting for an additional\n> pain coming from the differences between current and simple. If\n> current and simple are similar enough that their differences do not\n> matter, why wait for simple to be available everywhere and switch the\n> default to it, instead of using current as the default in the first\n> place?\n\n'simple' is an improvement over 'current' as a default, especially for\nbeginners, but 'current' is already reasonably good.\n\nSo, the long term goal is really to switch to 'simple', but people who\nuse different versions of Git won't be able to use it before a few\nyears. These people have several options:\n\n1) Keep push.default unset. This is not acceptable because they don't\n   want the big fat warning each time they push.\n\n2) Set push.default to 'matching', to keep the old behavior and squelsh\n   the warning. If they go this way, they will never see the default\n   change.\n\n3) Set push.default to 'current', in which case they have the same\n   behavior as 'simple', except for the safety feature of 'simple'\n   (refuse to push when the name doesn't match the upstream). They can't\n   expect anything better anyway since they are sometimes using a\n   machine which doesn't support 'simple' anyway.\n\nTo me, option 3) clearly seems to be the best option. I don't understand\nwhether you would advise 1), 2), or maybe a 4) that I would have missed.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"193973","messageId":"7va9zxvkyp.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":"vpqpq8t96zw.fsf@bauges.imag.fr","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-20T19:31:42Z","receivedAt":"2012-06-20T19:31:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> So, the long term goal is really to switch to 'simple', but people who\n> use different versions of Git won't be able to use it before a few\n> years. These people have several options:\n>\n> 1) Keep push.default unset. This is not acceptable because they don't\n>    want the big fat warning each time they push.\n\nYes, to them one of 'simple', 'current' or 'upstream' would be\nsensible (but they need to read up on them to see which one they\nwant).\n\n> 2) Set push.default to 'matching', to keep the old behavior and squelsh\n>    the warning. If they go this way, they will never see the default\n>    change.\n\nThis is not the audience of the quoted part of the message i.e. \"If\nyou want to use it before default changes\".  These people fall into\nthe \"If you want to keep the current default, set push.default to\n'matching'\" category, so it is irrelevant to the discussion.\n\n> 3) Set push.default to 'current', in which case they have the same\n>    behavior as 'simple', except for the safety feature of 'simple'\n>    (refuse to push when the name doesn't match the upstream). They can't\n>    expect anything better anyway since they are sometimes using a\n>    machine which doesn't support 'simple' anyway.\n\nAnd they will be frozen to 'current' even after their sysadmins\nupdate the version of git that support 'simple'.  \n\nTelling somebody who would blindly follow what was suggested to use\n'current' is what bothers me.\n"},{"id":"193981","messageId":"vpqwr317oo2.fsf@bauges.imag.fr","threadId":"30846","inReplyTo":"7va9zxvkyp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-06-20T19:45:33Z","receivedAt":"2012-06-20T19:45:33Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> 3) Set push.default to 'current', in which case they have the same\n>>    behavior as 'simple', except for the safety feature of 'simple'\n>>    (refuse to push when the name doesn't match the upstream). They can't\n>>    expect anything better anyway since they are sometimes using a\n>>    machine which doesn't support 'simple' anyway.\n>\n> And they will be frozen to 'current' even after their sysadmins\n> update the version of git that support 'simple'.  \n\nAnd so what? They will miss the safety feature of 'simple', but that's\nnot really a big deal.\n\n'simple' was not really designed to be _better_ than current or\nupstream, but to be more adapted as a default value, because 1) it's\nsafer, so nice for beginners and 2) follows the least surprise\nprinciple, as it does nothing in cases where there would be an\nambiguity. But once you're not really a beginner, the added value of\n'simple' is really small compared to 'current' or 'upstream'.\n\n> Telling somebody who would blindly follow what was suggested to use\n> 'current' is what bothers me.\n\nBut what alternative do we have?\n\nYou suggest that I remove the mention of 'current', but then what should\nusers do? Removing it sounds like replacing it with \"if you sometimes\nuse older versions of Git, you're doomed, sorry\" to me.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"193983","messageId":"7v62alvk2e.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":"7va9zxvkyp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-20T19:51:05Z","receivedAt":"2012-06-20T19:51:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Telling somebody who would blindly follow what was suggested to use\n> 'current' is what bothers me.\n\nThat is (quoting the difference between the previous round and this\none),\n\n static char warn_unspecified_push_default_msg[] =\n N_(\"push.default is unset; its implicit value is changing in\\n\"\n    \"Git 2.0 from 'matching' to 'simple'. To squelch this message\\n\"\n    \"and maintain the current behavior after the default changes, use:\\n\"\n    \"\\n\"\n    \"  git config --global push.default matching\\n\"\n    \"\\n\"\n    \"To squelch this message and adopt the new behavior now, use:\\n\"\n    \"\\n\"\n    \"  git config --global push.default simple\\n\"\n    \"\\n\"\n-   \"See 'git help config' and search for 'push.default' for further information.\");\n+   \"See 'git help config' and search for 'push.default' for further information.\\n\"\n+   \"(the 'simple' mode was introduced in Git 1.7.11. Use 'current' instead if\\n\"\n+   \"you sometimes use older versions of Git)\");\n\nThe latter half of the message is \"To *adopt* the *new behaviour\nnow*\" but setting it to 'current' is not adopting the new behaviour.\n\nPerhaps we should say more to help people decide which one to choose\nin this message.\n\n    ... changing in Git 2.0 from 'matching' to 'simple'.\n    'matching', which is the current default, pushes all branches\n    that exist at the remote.  'simple', which will be the new\n    default, pushes only the current branch to update the branch at\n    the remote of the same name (the 'simple' mode is only available\n    in Git 1.7.11 or newer; older versions of Git has a similar mode\n    called 'current').\n\n    You can squelch this message by picking your preferred default now,\n    e.g. running one of these:\n\n            git config push.default matching\n            git config push.default simple\n            git config push.default current\n\nor something?\n"},{"id":"194038","messageId":"vpqd34su0io.fsf@bauges.imag.fr","threadId":"30846","inReplyTo":"7v62alvk2e.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-06-21T15:50:55Z","receivedAt":"2012-06-21T15:50:55Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Perhaps we should say more to help people decide which one to choose\n> in this message.\n[...]\n>     You can squelch this message by picking your preferred default now,\n>     e.g. running one of these:\n>\n>             git config push.default matching\n>             git config push.default simple\n>             git config push.default current\n\nI don't see any added value. Seeing this, it's less clear to the user,\nand he may chose 'simple', and then complain that it breaks his older\nGit. Really, if 'simple' isn't an option for someone, why should we make\nthis someone think before chosing between 'current' an 'simple'?\n\nAlso, my version purposely made 'simple' more visible than 'current'\n(cut-and-paste ready alone on its line Vs within parenthesis), because\nthis is the one we want to advertise. Putting the 3 options at the same\nlevel is a regression to me.\n\nWe can rephrase the advice to make it clearer that 'simple' !=\n'current', like\n\n  (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n  'current' instead if you sometimes use older versions of Git)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"194041","messageId":"7vobocsipo.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":"vpqd34su0io.fsf@bauges.imag.fr","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-21T17:00:51Z","receivedAt":"2012-06-21T17:00:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Perhaps we should say more to help people decide which one to choose\n>> in this message.\n> [...]\n>>     You can squelch this message by picking your preferred default now,\n>>     e.g. running one of these:\n>>\n>>             git config push.default matching\n>>             git config push.default simple\n>>             git config push.default current\n>\n> I don't see any added value. Seeing this, it's less clear to the user,\n> and he may chose 'simple', and then complain that it breaks his older\n> Git. \n\nRe-read the part you omitted with [...].  Doesn't it say something\nabout \"only available\"?\n\n> Really, if 'simple' isn't an option for someone, why should we make\n> this someone think before chosing between 'current' an 'simple'?\n\nThis is not about choosing between simple and current when both are\navailable.  As [...] part tries to clearly state (and if it is\nunclear, please clarify it further), the new default \"simple\" is\nonly available in certain versions, and 'current' is the closest\napproximation for other versions.  So even though there are three\nchoices, it is really about choosing between 'matching' (push all\nrelevant and current branch does not matter) and 'simple/current'\n(push current  branch only).  We could make it like this:\n\n\te.g. running one of these:\n\n\t\tgit config push.default matching\n\t\tgit config push.default simple (or current)\n\nand it may make it clearer what choices are suggested.  The only\nreason I made it three lines is \"(or current)\" would make it harder\nfor people who want \"current only\" but runs older version of git in\nthe same repository to cut and paste.\n"},{"id":"194042","messageId":"vpq62aksicy.fsf@bauges.imag.fr","threadId":"30846","inReplyTo":"7vobocsipo.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-06-21T17:08:29Z","receivedAt":"2012-06-21T17:08:29Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Re-read the part you omitted with [...].  Doesn't it say something\n> about \"only available\"?\n\nIt does, but it seems you're trying hard to avoid telling the user \"you\nshould use 'current'\", where 'current' is the only reasonable option for\nthis user. I still don't understand what problem you're trying to solve.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"194043","messageId":"7vk3z0shri.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":"vpq62aksicy.fsf@bauges.imag.fr","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-21T17:21:21Z","receivedAt":"2012-06-21T17:21:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Re-read the part you omitted with [...].  Doesn't it say something\n>> about \"only available\"?\n>\n> It does, but it seems you're trying hard to avoid telling the user \"you\n> should use 'current'\", where 'current' is the only reasonable option for\n> this user. I still don't understand what problem you're trying to solve.\n\nI am avoiding to say \"you should use simple/current\".  Choice\nbetween matching and simple/current is for the user to make (mostly\ndictated by the project's workflow) and we cannot make a suggestion\nbetter than what user knows.\n\nChoice between simple and current is mechanically derivable. If the\nuser also uses older version of git, simple is not an option.\n"},{"id":"194045","messageId":"7v62aksgkv.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":"7vk3z0shri.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-21T17:46:56Z","receivedAt":"2012-06-21T17:46:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> Re-read the part you omitted with [...].  Doesn't it say something\n>>> about \"only available\"?\n>>\n>> It does, but it seems you're trying hard to avoid telling the user \"you\n>> should use 'current'\", where 'current' is the only reasonable option for\n>> this user. I still don't understand what problem you're trying to solve.\n>\n> I am avoiding to say \"you should use simple/current\".  Choice\n> between matching and simple/current is for the user to make (mostly\n> dictated by the project's workflow) and we cannot make a suggestion\n> better than what user knows.\n>\n> Choice between simple and current is mechanically derivable. If the\n> user also uses older version of git, simple is not an option.\n\nTo put it another way, I am questioning your \"where 'current is the\nonly reasonable option for this user\".  If it were truly the case,\nwhy would we be issuing a warning message?  Wouldn't we be instead\nsilently doing what 'simple' or 'current' would do?\n\nThe reason why we have this message is because either \"push the\ncurrent one and not others\" or \"push all relevant ones, regardless\nof the current\" are reasonable choices depending on the user, and\nbecause we had to choose one for the default, we previously chose\nthe latter but we are changing our mind and will default to the\nother one, no?\n"},{"id":"194056","messageId":"vpqlijfrd73.fsf@bauges.imag.fr","threadId":"30846","inReplyTo":"7vk3z0shri.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-06-22T07:57:36Z","receivedAt":"2012-06-22T07:57:36Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> Re-read the part you omitted with [...].  Doesn't it say something\n>>> about \"only available\"?\n>>\n>> It does, but it seems you're trying hard to avoid telling the user \"you\n>> should use 'current'\", where 'current' is the only reasonable option for\n>> this user. I still don't understand what problem you're trying to solve.\n>\n> I am avoiding to say \"you should use simple/current\".  Choice\n> between matching and simple/current is for the user to make (mostly\n> dictated by the project's workflow) and we cannot make a suggestion\n> better than what user knows.\n>\n> Choice between simple and current is mechanically derivable. If the\n> user also uses older version of git, simple is not an option.\n\nI do agree with that. My message tells the user to use 'current' instead\nof 'simple' when not appropriate, not to use 'current' instead of\n'matching', which would indeed be a nonsense. I thought it was clear\nenough, but we can make that more explicit. How about:\n\n  (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n  'current' instead of 'simple' if you sometimes use older versions of Git)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"194081","messageId":"7v7guzqluh.fsf@alter.siamese.dyndns.org","threadId":"30846","inReplyTo":"vpqlijfrd73.fsf@bauges.imag.fr","subject":"Re: [PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-22T17:48:22Z","receivedAt":"2012-06-22T17:48:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> I do agree with that. My message tells the user to use 'current' instead\n> of 'simple' when not appropriate, not to use 'current' instead of\n> 'matching', which would indeed be a nonsense. I thought it was clear\n> enough, but we can make that more explicit. How about:\n>\n>   (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n>   'current' instead of 'simple' if you sometimes use older versions of Git)\n\nYeah, that would work (the minority that need to pick 'current'\ncannot cut and paste, but that is not a big deal).\n\nAs I did not butcher the version you sent me when I queued it with\nmy rewrite, a follow-up patch to update it should be fairly minimal\n;-)\n\nThanks.\n"},{"id":"194152","messageId":"1340535697-14556-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"30846","inReplyTo":"7v7guzqluh.fsf@alter.siamese.dyndns.org","subject":"[PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-06-24T11:01:37Z","receivedAt":"2012-06-24T11:01:37Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"In preparation for flipping the default to the \"simple\" mode from\nthe \"matching\" mode that is the historical default, start warning\nusers when they rely on unconfigured \"git push\" to default to the\n\"matching\" mode.\n\nAlso, advertise for 'simple' where 'current' and 'upstream' are advised.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\nJunio C Hamano <gitster@pobox.com> writes:\n\n>>   (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n>>   'current' instead of 'simple' if you sometimes use older versions of Git)\n>\n> Yeah, that would work (the minority that need to pick 'current'\n> cannot cut and paste, but that is not a big deal).\n>\n> As I did not butcher the version you sent me when I queued it with\n> my rewrite, a follow-up patch to update it should be fairly minimal\n> ;-)\n\nHere it is.\n\n builtin/push.c       | 29 +++++++++++++++++++++++++++--\n t/t5541-http-push.sh |  5 ++++-\n 2 files changed, 31 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 08ccb89..9a0a035 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -147,12 +147,37 @@ static void setup_push_upstream(struct remote *remote, int simple)\n \tadd_refspec(refspec.buf);\n }\n \n+static char warn_unspecified_push_default_msg[] =\n+N_(\"push.default is unset; its implicit value is changing in\\n\"\n+   \"Git 2.0 from 'matching' to 'simple'. To squelch this message\\n\"\n+   \"and maintain the current behavior after the default changes, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default matching\\n\"\n+   \"\\n\"\n+   \"To squelch this message and adopt the new behavior now, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default simple\\n\"\n+   \"\\n\"\n+   \"See 'git help config' and search for 'push.default' for further information.\\n\"\n+   \"(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\\n\"\n+   \"'current' instead of 'simple' if you sometimes use older versions of Git)\");\n+\n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(\"%s\\n\", _(warn_unspecified_push_default_msg));\n+}\n+\n static void setup_default_push_refspecs(struct remote *remote)\n {\n \tswitch (push_default) {\n \tdefault:\n \tcase PUSH_DEFAULT_UNSPECIFIED:\n \t\tdefault_matching_used = 1;\n+\t\twarn_unspecified_push_default_configuration();\n \t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n@@ -186,8 +211,8 @@ static const char message_advice_pull_before_push[] =\n static const char message_advice_use_upstream[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\n \t   \"counterpart. If you did not intend to push that branch, you may want to\\n\"\n-\t   \"specify branches to push or set the 'push.default' configuration\\n\"\n-\t   \"variable to 'current' or 'upstream' to push only the current branch.\");\n+\t   \"specify branches to push or set the 'push.default' configuration variable\\n\"\n+\t   \"to 'simple', 'current' or 'upstream' to push only the current branch.\");\n \n static const char message_advice_checkout_pull_push[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\ndiff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh\nindex 5b170be..07fa199 100755\n--- a/t/t5541-http-push.sh\n+++ b/t/t5541-http-push.sh\n@@ -64,7 +64,10 @@ test_expect_success 'no empty path components' '\n \n test_expect_success 'clone remote repository' '\n \trm -rf test_repo_clone &&\n-\tgit clone $HTTPD_URL/smart/test_repo.git test_repo_clone\n+\tgit clone $HTTPD_URL/smart/test_repo.git test_repo_clone &&\n+\t(\n+\t\tcd test_repo_clone && git config push.default matching\n+\t)\n '\n \n test_expect_success 'push to remote repository (standard)' '\n-- \n1.7.11.5.g0c7e058.dirty\n"}]}