summaryrefslogtreecommitdiff
path: root/t/t5528-push-default.sh
AgeCommit message (Collapse)AuthorFilesLines
2015-03-10t5528: do not fail with FreeBSD shellLibravatar Kyle J. McKay1-2/+2
The FreeBSD shell converts this expression: git ${1:+-c push.default="$1"} push to this when "$1" is not empty: git "-c push.default=$1" push which causes git to fail. To avoid this we simply break up the expansion into two parts so that the whitespace which creates two arguments instead of one is outside the ${...} like so: git ${1:+-c} ${1:+push.default="$1"} push This has the desired effect on all platforms allowing the test to pass on FreeBSD. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-30push: truly use "simple" as default, not "upstream"Libravatar Jeff King1-2/+30
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24t/t5528-push-default: test pushdefault workflowsLibravatar Ramkumar Ramachandra1-0/+57
Introduce test_pushdefault_workflows(), and test that all push.default modes work with central and triangular workflows as expected. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24t/t5528-push-default: generalize test_push_*Libravatar Ramkumar Ramachandra1-2/+4
The setup creates two bare repositories: repo1 and repo2, but test_push_commit() hard-codes checking in repo1 for the actual output. Generalize it and its caller, test_push_success(), to optionally accept a third argument to specify the name of the repository to check for actual output. We will use this in the next patch. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-19t/t5528-push-default: remove redundant test_config linesLibravatar Ramkumar Ramachandra1-2/+0
The line test_config push.default upstream appears unnecessarily in two tests, as the final test_push_failure sets push.default before pushing anyway. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24push: introduce new push.default mode "simple"Libravatar Matthieu Moy1-0/+44
When calling "git push" without argument, we want to allow Git to do something simple to explain and safe. push.default=matching is unsafe when used to push to shared repositories, and hard to explain to beginners in some contexts. It is debatable whether 'upstream' or 'current' is the safest or the easiest to explain, so introduce a new mode called 'simple' that is the intersection of them: push to the upstream branch, but only if it has the same name remotely. If not, give an error that suggests the right command to push explicitely to 'upstream' or 'current'. A question is whether to allow pushing when no upstream is configured. An argument in favor of allowing the push is that it makes the new mode work in more cases. On the other hand, refusing to push when no upstream is configured encourages the user to set the upstream, which will be beneficial on the next pull. Lacking better argument, we chose to deny the push, because it will be easier to change in the future if someone shows us wrong. Original-patch-by: Jeff King <peff@peff.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24t5528-push-default.sh: add helper functionsLibravatar Matthieu Moy1-7/+27
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-05push: error out when the "upstream" semantics does not make senseLibravatar Junio C Hamano1-0/+54
The user can say "git push" without specifying any refspec. When using the "upstream" semantics via the push.default configuration, the user wants to update the "upstream" branch of the current branch, which is the branch at a remote repository the current branch is set to integrate with, with this command. However, there are cases that such a "git push" that uses the "upstream" semantics does not make sense: - The current branch does not have branch.$name.remote configured. By definition, "git push" that does not name where to push to will not know where to push to. The user may explicitly say "git push $there", but again, by definition, no branch at repository $there is set to integrate with the current branch in this case and we wouldn't know which remote branch to update. - The current branch does have branch.$name.remote configured, but it does not specify branch.$name.merge that names what branch at the remote this branch integrates with. "git push" knows where to push in this case (or the user may explicitly say "git push $remote" to tell us where to push), but we do not know which remote branch to update. - The current branch does have its remote and upstream branch configured, but the user said "git push $there", where $there is not the remote named by "branch.$name.remote". By definition, no branch at repository $there is set to integrate with the current branch in this case, and this push is not meant to update any branch at the remote repository $there. The first two cases were already checked correctly, but the third case was not checked and we ended up updating the branch named branch.$name.merge at repository $there, which was totally bogus. Signed-off-by: Junio C Hamano <gitster@pobox.com>