kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Dennis Kaarsemaker	b284495e93	push: test pushing ambiguously named branches Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Kyle J. McKay	ce026cc7e2	t5528: do not fail with FreeBSD shell 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>	10 years ago
Jeff King	00a6fa0720	push: truly use "simple" as default, not "upstream" 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>	10 years ago
Ramkumar Ramachandra	6e1696b7c4	t/t5528-push-default: test pushdefault workflows 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>	12 years ago
Ramkumar Ramachandra	396243fa47	t/t5528-push-default: generalize test_push_* 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>	12 years ago
Ramkumar Ramachandra	3cb8a5ff17	t/t5528-push-default: remove redundant test_config lines 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>	12 years ago
Matthieu Moy	b55e677522	push: introduce new push.default mode "simple" 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>	13 years ago
Matthieu Moy	321e75c5dc	t5528-push-default.sh: add helper functions Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	135dadef71	push: error out when the "upstream" semantics does not make sense 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>	13 years ago