From: Eric Sunshine <sunshine@sunshineco.com>
To: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] push: make '-u' have default arguments
Date: Tue, 7 Dec 2021 17:14:15 -0500 [thread overview]
Message-ID: <CAPig+cRxU=pT-qCp-xpHcoae45oxz1d-eRh+QF-SJFM3B-6KyQ@mail.gmail.com> (raw)
In-Reply-To: <20211207182300.4361-2-chakrabortyabhradeep79@gmail.com>
On Tue, Dec 7, 2021 at 4:11 PM Abhradeep Chakraborty
<chakrabortyabhradeep79@gmail.com> wrote:
> [...]
> Teach "git push -u" not to require repository and refspec. When
> the user do not give what repository to push to, or which
> branch(es) to push, behave as if the default remote repository
> and a refspec (depending on the "push.default" configuration)
> are given.
> [...]
> Signed-off-by: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
This is not a proper review... just some superficial comments from
scanning my eye over the patch...
> diff --git a/t/t5523-push-upstream.sh b/t/t5523-push-upstream.sh
> @@ -60,6 +60,75 @@ test_expect_success 'push -u :topic_2' '
> +default_u_setup() {
> + git checkout main
> + remote=$(git config --get branch.main.remote)
> + if [ ! -z "$remote" ]; then
> + git branch --unset-upstream
> + fi
> + git config push.default $1
> + git config remote.pushDefault upstream
> +}
A few issues...
* since callers of this function incorporate it into their &&-chains,
the body of the function itself should probably also have an intact
&&-chain
* use `test` rather than `[`
* `then` goes on its own line
* probably want to use test_config() here rather than raw `git config`
* `! -z` can be written more simply as `-n`
Taking the above into account, gives:
default_u_setup() {
git checkout main &&
remote=$(git config --default '' --get branch.main.remote) &&
if test -n "$remote"
then
git branch --unset-upstream
fi &&
test_config push.default $1 &&
test_config remote.pushDefault upstream
}
The `--default` ensures that `git config` will exit with a success
code which is important now that it's part of the &&-chain.
Alternatively, you could skip the dance of checking for
`branch.main.remote` and just call `git branch --unset-upstream`
unconditionally, but wrap it with test_might_fail() so it can be part
of the &&-chain without worrying about whether that command succeeds
or fails:
default_u_setup() {
git checkout main &&
test_might_fail git branch --unset-upstream &&
test_config push.default $1 &&
test_config remote.pushDefault upstream
}
> +test_expect_success 'push -u with push.default=simple' '
> + default_u_setup simple &&
> + git push -u &&
> + check_config main upstream refs/heads/main &&
> + git push -u upstream main:other &&
> + git push -u &&
> + check_config main upstream refs/heads/main
> +'
> +
> +test_expect_success 'push -u with push.default=current' '
> + default_u_setup current &&
> + git push -u &&
> + check_config main upstream refs/heads/main &&
> + git push -u upstream main:other &&
> + git push -u &&
> + check_config main upstream refs/heads/main
> +'
> +
> +test_expect_success 'push -u with push.default=upstream' '
> + default_u_setup upstream &&
> + git push -u &&
> + check_config main upstream refs/heads/main &&
> + git push -u upstream main:other &&
> + git push -u &&
> + check_config main upstream refs/heads/main
> +'
When a number of tests have nearly identical bodies like this, it is
sometimes clearer and more convenient to turn them into a for-loop
like this:
for i in simple current upstream
do
test_expect_success "push -u with push.default=$i" '
default_u_setup $i &&
git push -u &&
check_config main upstream refs/heads/main &&
git push -u upstream main:other &&
git push -u &&
check_config main upstream refs/heads/main
'
done
> +check_empty_config() {
> + test_expect_code 1 git config "branch.$1.remote"
> + test_expect_code 1 git config "branch.$1.merge"
> +}
As above, because calls to this function are part of the &&-chain in
test bodies, it is important for the &&-chain to be intact in the
function too. It's especially important in this case since this
function is actually checking for specific conditions. As it's
currently written -- with a broken &&-chain -- if the first
test_expect_code() fails, we'll never know about it since that exit
code gets lost; only the exit code from the second test_expect_code()
has any bearing on the overall result of the test.
> +test_expect_success 'progress messagesdo not go to non-tty (default -u)' '
s/messagesdo/messages do/
> + ensure_fresh_upstream &&
> +
> + # skip progress messages, since stderr is non-tty
> + git push -u >out 2>err &&
> + test_i18ngrep ! "Writing objects" err
> +'
The captured stdout in `out` doesn't seem to be used, so it's probably
better to drop that redirection.
> +test_expect_success 'progress messages go to non-tty with default -u (forced)' '
> + ensure_fresh_upstream &&
> +
> + # force progress messages to stderr, even though it is non-tty
> + git push -u --progress >out 2>err &&
> + test_i18ngrep "Writing objects" err
> +'
Ditto. And repeat for the remaining tests.
next prev parent reply other threads:[~2021-12-07 22:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 14:43 [RFC PATCH 0/1] making --set-upstream have default arguments Abhradeep Chakraborty
2021-12-02 14:43 ` [RFC PATCH 1/1] push: make '-u' " Abhradeep Chakraborty
2021-12-02 18:24 ` Junio C Hamano
2021-12-03 8:14 ` Abhradeep Chakraborty
2021-12-03 17:29 ` Junio C Hamano
2021-12-03 19:27 ` Abhradeep Chakraborty
2021-12-03 11:32 ` [RFC PATCH 0/1] making --set-upstream " Philip Oakley
2021-12-03 16:03 ` Abhradeep Chakraborty
2021-12-03 16:46 ` Philip Oakley
2021-12-03 17:28 ` Abhradeep Chakraborty
2021-12-07 18:22 ` [PATCH v2 " Abhradeep Chakraborty
2021-12-07 18:23 ` [PATCH v2 1/1] push: make '-u' " Abhradeep Chakraborty
2021-12-07 22:14 ` Eric Sunshine [this message]
2021-12-08 6:12 ` [PATCH v2 1/1] push: make '-u' have default argument Abhradeep Chakraborty
2021-12-09 10:15 ` [PATCH v3 0/1] making --set-upstream have default arguments Abhradeep Chakraborty
2021-12-09 10:15 ` [PATCH v3 1/1] push: make '-u' " Abhradeep Chakraborty
2022-01-01 14:37 ` [PATCH v4 0/1] making --set-upstream " Abhradeep Chakraborty
2022-01-01 14:37 ` [PATCH v4 1/1] push: make 'set-upstream' have dafault arguments Abhradeep Chakraborty
2022-01-04 3:46 ` Junio C Hamano
2022-01-04 13:28 ` Abhradeep Chakraborty
2022-01-04 20:35 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPig+cRxU=pT-qCp-xpHcoae45oxz1d-eRh+QF-SJFM3B-6KyQ@mail.gmail.com' \
--to=sunshine@sunshineco.com \
--cc=chakrabortyabhradeep79@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).