All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.