summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-09-14Merge branch 'mh/abspath'Libravatar Junio C Hamano2-18/+59
* mh/abspath: t0060: split absolute path test in two to exercise some of it on Windows t0060: verify that real_path() removes extra slashes real_path(): properly handle nonexistent top-level paths t0060: verify that real_path() works correctly with absolute paths real_path(): reject the empty string t0060: verify that real_path() fails if passed the empty string absolute_path(): reject the empty string t0060: verify that absolute_path() fails if passed the empty string t0060: move tests of real_path() from t0000 to here
2012-09-14Merge branch 'dj/fetch-all-tags'Libravatar Junio C Hamano1-0/+30
"git fetch --all", when passed "--no-tags", did not honor the "--no-tags" option while fetching from individual remotes (the same issue existed with "--tags", but combination "--all --tags" makes much less sense than "--all --no-tags"). * dj/fetch-all-tags: fetch --all: pass --tags/--no-tags through to each remote
2012-09-14Merge branch 'rj/tap-fix'Libravatar Junio C Hamano4-63/+81
* rj/tap-fix: test-lib.sh: Suppress the "passed all ..." message if no tests run test-lib.sh: Add check for invalid use of 'skip_all' facility test-lib.sh: Fix some shell coding style violations t4016-*.sh: Skip all tests rather than each test t3902-*.sh: Skip all tests rather than each test t3300-*.sh: Fix a TAP parse error
2012-09-12Merge branch 'nd/maint-remote-remove'Libravatar Junio C Hamano2-3/+3
* nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'
2012-09-11Merge branch 'rj/test-regex'Libravatar Junio C Hamano1-0/+5
Git ships with a fall-back regexp implementation for platforms with buggy regexp library; give people a tool to see if they should be using it on their platform. * rj/test-regex: test-regex: Add a test to check for a bug in the regex routines
2012-09-10Merge branch 'cn/branch-set-upstream-to'Libravatar Junio C Hamano1-0/+70
"git branch --set-upstream origin/master" is a common mistake to create a local branch 'origin/master' and set it to integrate with the current branch. With a plan to deprecate this option, introduce "git branch (-u|--set-upstream-to) origin/master" that sets the current branch to integrate with 'origin/master' remote tracking branch. * cn/branch-set-upstream-to: branch: deprecate --set-upstream and show help if we detect possible mistaken use branch: add --unset-upstream option branch: introduce --set-upstream-to
2012-09-10Merge branch 'mz/cherry-pick-cmdline-order'Libravatar Junio C Hamano2-0/+25
"git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order, which is not what the user who said "A C B" naturally expects. * mz/cherry-pick-cmdline-order: cherry-pick/revert: respect order of revisions to pick demonstrate broken 'git cherry-pick three one two' teach log --no-walk=unsorted, which avoids sorting
2012-09-10Merge branch 'jk/maint-quiet-is-synonym-to-s-in-log'Libravatar Junio C Hamano1-0/+12
We tried to bend backwards to allow "--quiet" to be a synonym as "-s" when given as e.g. "git show --quiet", but did not quite succeed. * jk/maint-quiet-is-synonym-to-s-in-log: log: fix --quiet synonym for -s
2012-09-10t0060: split absolute path test in two to exercise some of it on WindowsLibravatar Johannes Sixt1-2/+6
Only the first half of the test works only on POSIX, the second half passes on Windows as well. A later test "real path removes other extra slashes" looks very similar, but it does not make sense to split it in the same way: When two slashes are prepended in front of an absolute DOS-style path on Windows, the meaning of the path is changed (//server/share style), so that the test cannot pass on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-07Merge branch 'jk/maint-http-half-auth-push'Libravatar Junio C Hamano6-75/+127
Pushing to smart HTTP server with recent Git fails without having the username in the URL to force authentication, if the server is configured to allow GET anonymously, while requiring authentication for POST. * jk/maint-http-half-auth-push: http: prompt for credentials on failed POST http: factor out http error code handling t: test http access to "half-auth" repositories t: test basic smart-http authentication t/lib-httpd: recognize */smart/* repos as smart-http t/lib-httpd: only route auth/dumb to dumb repos t5550: factor out http auth setup t5550: put auth-required repo in auth/dumb
2012-09-07Merge branch 'jc/apply-binary-p0'Libravatar Junio C Hamano1-21/+33
"git apply -p0" did not parse pathnames on "diff --git" line correctly. This caused patches that had pathnames in no other places to be mistakenly rejected (most notably, binary patch that does not rename nor change mode). Textual patches, renames or mode changes have preimage and postimage pathnames in different places in a form that can be parsed unambiguously and did not suffer from this problem. * jc/apply-binary-p0: apply: compute patch->def_name correctly under -p0
2012-09-07Merge branch 'jc/dotdot-is-parent-directory'Libravatar Junio C Hamano2-0/+21
"git log .." errored out saying it is both rev range and a path when there is no disambiguating "--" is on the command line. Update the command line parser to interpret ".." as a path in such a case. * jc/dotdot-is-parent-directory: specifying ranges: we did not mean to make ".." an empty set
2012-09-07Merge branch 'kk/maint-for-each-ref-multi-sort'Libravatar Junio C Hamano1-0/+10
"git for-each-ref" did not currectly support more than one --sort option. * kk/maint-for-each-ref-multi-sort: for-each-ref: Fix sort with multiple keys t6300: test sort with multiple keys
2012-09-07Merge branch 'pw/p4-use-client-spec-branch-detection'Libravatar Junio C Hamano3-17/+94
Fix "git p4" when "--use-client-spec" and "--detect-branches" are used together (the command used to misdetect branches). * pw/p4-use-client-spec-branch-detection: git p4: make branch detection work with --use-client-spec git p4: do wildcard decoding in stripRepoPath git p4: set self.branchPrefixes in initialization git p4 test: add broken --use-client-spec --detect-branches tests git p4 test: move client_view() function to library
2012-09-07Merge branch 'nd/i18n-poison-test-updates'Libravatar Junio C Hamano23-53/+83
Update tests that can be broken with gettext-poison builds. * nd/i18n-poison-test-updates: Fix tests under GETTEXT_POISON on parseopt Fix tests under GETTEXT_POISON on git-remote Fix tests under GETTEXT_POISON on pack-object Fix tests under GETTEXT_POISON on git-apply Fix tests under GETTEXT_POISON on diffstat Fix tests under GETTEXT_POISON on git-stash Fix tests under GETTEXT_POISON on relative dates
2012-09-07fetch --all: pass --tags/--no-tags through to each remoteLibravatar Dan Johnson1-0/+30
When fetch is invoked with --all, we need to pass the tag-following preference to each individual fetch; without this, we will always auto-follow tags, preventing us from fetching the remote tags into a remote-specific namespace, for example. Reported-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Dan Johnson <ComputerDruid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that real_path() removes extra slashesLibravatar Michael Haggerty1-0/+18
Adjusted for Windows by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06real_path(): properly handle nonexistent top-level pathsLibravatar Michael Haggerty1-1/+1
The change has two points: 1. Do not strip off a leading slash, because that erroneously turns an absolute path into a relative path. 2. Do not remove slashes from groups of multiple slashes; instead let chdir() handle them. It could be, for example, that it wants to leave leading double-slashes alone. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that real_path() works correctly with absolute pathsLibravatar Michael Haggerty1-1/+11
There is currently a bug: if passed an absolute top-level path that doesn't exist (e.g., "/foo") it incorrectly interprets the path as a relative path (e.g., returns "$(pwd)/foo"). So mark the test as failing. These tests are skipped on Windows because test-path-utils operates on a DOS-style absolute path even if a POSIX style absolute path is passed as argument. Adjusted for Windows by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06real_path(): reject the empty stringLibravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that real_path() fails if passed the empty stringLibravatar Michael Haggerty1-0/+4
It doesn't, so mark the test as failing. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06absolute_path(): reject the empty stringLibravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that absolute_path() fails if passed the empty stringLibravatar Michael Haggerty1-0/+4
It doesn't, so mark the test as failing. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: move tests of real_path() from t0000 to hereLibravatar Michael Haggerty2-18/+19
Suggested by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06remote: prefer subcommand name 'remove' to 'rm'Libravatar Nguyễn Thái Ngọc Duy2-3/+3
All remote subcommands are spelled out words except 'rm'. 'rm', being a popular UNIX command name, may mislead users that there are also 'ls' or 'mv'. Use 'remove' to fit with the rest of subcommands. 'rm' is still supported and used in the test suite. It's just not widely advertised. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'sz/submodule-force-update'Libravatar Junio C Hamano1-0/+12
"git submodule update --force" used to leave the working tree of the submodule intact when there were local changes. It is more intiutive to make "--force" a sign to run "checkout -f" to overwrite them. * sz/submodule-force-update: Make 'git submodule update --force' always check out submodules.
2012-09-03Merge branch 'ph/stash-rerere'Libravatar Junio C Hamano1-0/+38
"git stash" internally used "git merge-recursive" backend, which did not trigger "rerere" upon conflicts unlike other mergy operations. * ph/stash-rerere: stash: invoke rerere in case of conflict test: git-stash conflict sets up rerere
2012-09-03Merge branch 'cw/cherry-pick-allow-empty-message'Libravatar Junio C Hamano1-0/+5
"git cherry-pick" by default stops when it sees a commit without any log message. The "--allow-empty-message" option can be used to silently proceed. * cw/cherry-pick-allow-empty-message: cherry-pick: add --allow-empty-message option
2012-09-02test-lib.sh: Suppress the "passed all ..." message if no tests runLibravatar Ramsay Jones1-1/+4
If a test script issues a test_done without executing any tests, for example when using the 'skip_all' facility, the output looks something like this: $ ./t9159-git-svn-no-parent-mergeinfo.sh # passed all 0 test(s) 1..0 # SKIP skipping git svn tests, svn not found $ The "passed all 0 test(s)" comment line, while correct, looks a little strange. Add a check to suppress this message if no tests have actually been run. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02test-lib.sh: Add check for invalid use of 'skip_all' facilityLibravatar Ramsay Jones1-0/+4
The 'skip_all' facility cannot be used after one or more tests have been executed using (for example) 'test_expect_success'. To do so results in invalid TAP output, which leads to 'prove' complaining of "Parse errors: No plan found in TAP output". Add a check for such invalid usage and abort the test with an error message to alert the test author. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02test-lib.sh: Fix some shell coding style violationsLibravatar Ramsay Jones1-22/+38
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02t4016-*.sh: Skip all tests rather than each testLibravatar Ramsay Jones1-11/+9
Each test in this file is skipped if the TABS_IN_FILENAMES test prerequisite is set. Use the 'skip_all' facility at the head of the file to skip all of the tests instead. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02t3902-*.sh: Skip all tests rather than each testLibravatar Ramsay Jones1-16/+15
Each test in this file is skipped if the TABS_IN_FILENAMES test prerequisite is set. Use the 'skip_all' facility at the head of the file to skip all of the tests instead. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02t3300-*.sh: Fix a TAP parse errorLibravatar Ramsay Jones1-13/+11
At present, running the t3300-*.sh test on cygwin looks like: $ cd t $ ./t3300-funny-names.sh ok 1 - setup # passed all 1 test(s) 1..1 # SKIP Your filesystem does not allow tabs in filenames $ Unfortunately, this is not valid TAP output, which prove notes as follows: $ prove --exec sh t3300-funny-names.sh t3300-funny-names.sh .. All 1 subtests passed Test Summary Report ------------------- t3300-funny-names.sh (Wstat: 0 Tests: 1 Failed: 0) Parse errors: No plan found in TAP output Files=1, Tests=1, 2 wallclock secs ( 0.05 usr 0.00 sys + \ 0.90 cusr 0.49 csys = 1.43 CPU) Result: FAIL $ This is due to the 'trailing_plan' having a 'skip_directive' attached to it. This is not allowed by the TAP grammar, which only allows a 'leading_plan' to be followed by an optional 'skip_directive'. (see perldoc TAP::Parser::Grammar). A trailing_plan is one that appears in the TAP output after one or more test status lines (that start 'not '? 'ok ' ...), whereas a leading_plan must appear before all test status lines (if any). In practice, this means that the test script cannot contain a use of the 'skip all' facility: skip_all='Some reason to skip *all* tests in this file' test_done after having already executed one or more tests with (for example) 'test_expect_success'. Unfortunately, this is exactly what this test script is doing. The first 'setup' test is actually used to determine if the test prerequisite is satisfied by the filesystem (ie does it allow tabs in filenames?). In order to fix the parse errors, place the code to determine the test prerequisite at the top level of the script, prior to the first test, rather than as a parameter to test_expect_success. This allows us to correctly use 'skip_all', thus: $ ./t3300-funny-names.sh # passed all 0 test(s) 1..0 # SKIP Your filesystem does not allow tabs in filenames $ $ prove --exec sh t3300-funny-names.sh t3300-funny-names.sh .. skipped: Your filesystem does not \ allow tabs in filenames Files=1, Tests=0, 2 wallclock secs ( 0.02 usr 0.03 sys + \ 0.84 cusr 0.41 csys = 1.29 CPU) Result: NOTESTS $ Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02test-regex: Add a test to check for a bug in the regex routinesLibravatar Ramsay Jones1-0/+5
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30cherry-pick/revert: respect order of revisions to pickLibravatar Martin von Zweigbergk1-1/+1
When giving multiple individual revisions to cherry-pick or revert, as in 'git cherry-pick A B' or 'git revert B A', one would expect them to be picked/reverted in the order given on the command line. They are instead ordered by their commit timestamp -- in chronological order for "cherry-pick" and in reverse chronological order for "revert". This matches the order in which one would usually give them on the command line, making this bug somewhat hard to notice. Still, it has been reported at least once before [1]. It seems like the chronological sorting happened by accident because the revision walker has traditionally always sorted commits in reverse chronological order when rev_info.no_walk was enabled. In the case of 'git revert B A' where B is newer than A, this sorting is a no-op. For 'git cherry-pick A B', the sorting would reverse the arguments, but because the sequencer also flips the rev_info.reverse flag when picking (as opposed to reverting), the end result is a chronological order. The rev_info.reverse flag was probably flipped so that the revision walker emits B before C in 'git cherry-pick A..C'; that it happened to effectively undo the unexpected sorting done when not walking, was probably a coincidence that allowed this bug to happen at all. Fix the bug by telling the revision walker not to sort the commits when not walking. The only case we want to reverse the order is now when cherry-picking and walking revisions (rev_info.no_walk = 0). [1] http://thread.gmane.org/gmane.comp.version-control.git/164794 Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30demonstrate broken 'git cherry-pick three one two'Libravatar Martin von Zweigbergk1-0/+15
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't currently work. Add a test case to demonstrate it. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30teach log --no-walk=unsorted, which avoids sortingLibravatar Martin von Zweigbergk1-0/+10
When 'git log' is passed the --no-walk option, no revision walk takes place, naturally. Perhaps somewhat surprisingly, however, the provided revisions still get sorted by commit date. So e.g 'git log --no-walk HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result (unless the two revisions share the commit date, in which case they will retain the order given on the command line). As the commit that introduced --no-walk (8e64006 (Teach revision machinery about --no-walk, 2007-07-24)) points out, the sorting is intentional, to allow things like git log --abbrev-commit --pretty=oneline --decorate --all --no-walk to show all refs in order by commit date. But there are also other cases where the sorting is not wanted, such as <command producing revisions in order> | git log --oneline --no-walk --stdin To accomodate both cases, leave the decision of whether or not to sort up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting to 'sorted' for backward-compatibility reasons. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30branch: deprecate --set-upstream and show help if we detect possible ↵Libravatar Carlos Martín Nieto1-0/+34
mistaken use This interface is error prone, and a better one (--set-upstream-to) exists. Add a message listing the alternatives and suggest how to fix a --set-upstream invocation in case the user only gives one argument which causes a local branch with the same name as a remote-tracking one to be created. The typical case is git branch --set-upstream origin/master when the user meant git branch --set-upstream master origin/master assuming that the current branch is master. Show a message telling the user how to undo their action and get what they wanted. For the command above, the message would be The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch origin/master set up to track local branch master. If you wanted to make 'master' track 'origin/master', do this: git branch -d origin/master git branch --set-upstream-to origin/master Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30branch: add --unset-upstream optionLibravatar Carlos Martín Nieto1-0/+22
We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets this information. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-29Merge branch 'ef/win32-cred-helper'Libravatar Junio C Hamano1-0/+4
Credential helper for Win32 to allow access to the keychain of the logged-in user. * ef/win32-cred-helper: contrib: add win32 credential-helper
2012-08-29Merge branch 'hv/submodule-path-unmatch'Libravatar Junio C Hamano1-4/+22
* hv/submodule-path-unmatch: Let submodule command exit with error status if path does not exist
2012-08-29Merge branch 'mz/empty-rebase-test'Libravatar Junio C Hamano1-1/+17
* mz/empty-rebase-test: add tests for 'git rebase --keep-empty'
2012-08-28log: fix --quiet synonym for -sLibravatar Jeff King1-0/+12
Originally the "--quiet" option was parsed by the diff-option parser into the internal QUICK option. This had the effect of silencing diff output from the log (which was not intended, but happened to work and people started to use it). But it also had other odd side effects at the diff level (for example, it would suppress the second commit in "git show A B"). To fix this, commit 1c40c36 converted log to parse-options and handled the "quiet" option separately, not passing it on to the diff code. However, it simply ignored the option, which was a regression for people using it as a synonym for "-s". Commit 01771a8 then fixed that by interpreting the option to add DIFF_FORMAT_NO_OUTPUT to the list of output formats. However, that commit did not fix it in all cases. It sets the flag after setup_revisions is called. Naively, this makes sense because you would expect the setup_revisions parser to overwrite our output format flag if "-p" or another output format flag is seen. However, that is not how the NO_OUTPUT flag works. We actually store it in the bit-field as just another format. At the end of setup_revisions, we call diff_setup_done, which post-processes the bitfield and clears any other formats if we have set NO_OUTPUT. By setting the flag after setup_revisions is done, diff_setup_done does not have a chance to make this tweak, and we end up with other format options still set. As a result, the flag would have no effect in "git log -p --quiet" or "git show --quiet". Fix it by setting the format flag before the call to setup_revisions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Merge branch 'js/grep-patterntype-config'Libravatar Junio C Hamano1-0/+181
"grep" learned to use a non-standard pattern type by default if a configuration variable tells it to. * js/grep-patterntype-config: grep: add a grep.patternType configuration setting
2012-08-27Merge branch 'bc/receive-pack-stdout-protection'Libravatar Junio C Hamano1-0/+35
When "git push" triggered the automatic gc on the receiving end, a message from "git prune" that said it was removing cruft leaked to the standard output, breaking the communication protocol. * bc/receive-pack-stdout-protection: receive-pack: do not leak output from auto-gc to standard output t/t5400: demonstrate breakage caused by informational message from prune
2012-08-27Merge branch 'ab/diff-write-incomplete-line'Libravatar Junio C Hamano1-0/+30
The output from "git diff -B" for a file that ends with an incomplete line did not put "\ No newline..." on a line of its own. * ab/diff-write-incomplete-line: Fix '\ No newline...' annotation in rewrite diffs
2012-08-27Merge branch 'jc/maint-t7406-rev-parse-max-count-huh'Libravatar Junio C Hamano1-8/+8
Test clean-up, with no behaviour change. * jc/maint-t7406-rev-parse-max-count-huh: t7406: fix misleading "rev-parse --max-count=1 HEAD"
2012-08-27Merge branch 'jk/maint-null-in-trees'Libravatar Junio C Hamano3-0/+128
We do not want a link to 0{40} object stored anywhere in our objects. * jk/maint-null-in-trees: fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value
2012-08-27Merge branch 'mm/push-default-switch-warning'Libravatar Junio C Hamano1-1/+4
In the next major release, we will switch "git push [$there]" that does not say what to push from the traditional "matching" to the updated "simple" semantics, that pushes the current branch to the branch with the same name only when the current branch is set to integrate with that remote branch (all other cases will error out). * mm/push-default-switch-warning: push: start warning upcoming default change for push.default