diff options
author | Jeff King <peff@peff.net> | 2014-11-26 22:43:06 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-11-30 18:11:25 -0800 |
commit | 00a6fa0720283b93eb011adcfea850fe21345548 (patch) | |
tree | 46f0911d48e5fdf48dd9c3e4634e3241af61d473 /patch-ids.c | |
parent | Git 2.0 (diff) | |
download | tgif-00a6fa0720283b93eb011adcfea850fe21345548.tar.xz |
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>
Diffstat (limited to 'patch-ids.c')
0 files changed, 0 insertions, 0 deletions