git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Mehul Jain <mehul.jain2029@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Paul Tan <pyokagan@gmail.com>
Subject: Re: [PATCH v10 2/2] pull --rebase: add --[no-]autostash flag
Date: Fri, 25 Mar 2016 04:31:35 -0400	[thread overview]
Message-ID: <CAPig+cSdegoGNCMBMcHyEYiE+LUzixvdk-qu0Q-zbFvatX2=KA@mail.gmail.com> (raw)
In-Reply-To: <1458591170-28079-1-git-send-email-mehul.jain2029@gmail.com>

On Mon, Mar 21, 2016 at 4:12 PM, Mehul Jain <mehul.jain2029@gmail.com> wrote:
> If rebase.autoStash configuration variable is set, there is no way to
> override it for "git pull --rebase" from the command line.
>
> Teach "git pull --rebase" the --[no-]autostash command line flag which
> overrides the current value of rebase.autoStash, if set. As "git rebase"
> understands the --[no-]autostash option, it's just a matter of passing
> the option to underlying "git rebase" when "git pull --rebase" is called.

This version of the patch (coupled with patch 1/2) is a pleasant
improvement over previous versions due to the cleaner structure, less
noisy diff, and general simplicity (thus easier to reason about and
review).

See below for a nit and some comments about the tests.

> Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com>
> ---
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> @@ -256,6 +256,76 @@ test_expect_success 'pull --rebase succeeds with dirty working directory and reb
>         test "$(cat file)" = "modified again"
>  '
>
> +test_expect_success 'pull --rebase --autostash & rebase.autostash=true' '

Nit: Some of the test titles spell this as "rebase.autostash" while
others use "rebase.autoStash".

> +       test_config rebase.autostash true &&
> +       git reset --hard before-rebase &&
> +       echo dirty >new_file &&
> +       git add new_file &&
> +       git pull --rebase --autostash . copy &&
> +       test_cmp_rev HEAD^ copy &&
> +       test "$(cat new_file)" = dirty &&
> +       test "$(cat file)" = "modified again"
> +'
> +
> +test_expect_success 'pull --rebase --autostash & rebase.autoStash=false' '
> +       test_config rebase.autostash false &&
> +       git reset --hard before-rebase &&
> +       echo dirty >new_file &&
> +       git add new_file &&
> +       git pull --rebase --autostash . copy &&
> +       test_cmp_rev HEAD^ copy &&
> +       test "$(cat new_file)" = dirty &&
> +       test "$(cat file)" = "modified again"
> +'
> +
> +test_expect_success 'pull --rebase: --autostash & rebase.autoStash unset' '

The title says that this is testing with rebase.autoStash unset,
however, the test itself doesn't take any action to ensure that it is
indeed unset. As with the two above tests which explicitly set
rebase.autoStash, this test should explicitly unset rebase.autoStash
to ensure consistent results even if some future change somehow
pollutes the configuration globally. Therefore:

    test_unconfig rebase.autostash &&

> +       git reset --hard before-rebase &&
> +       echo dirty >new_file &&
> +       git add new_file &&
> +       git pull --rebase --autostash . copy &&
> +       test_cmp_rev HEAD^ copy &&
> +       test "$(cat new_file)" = dirty &&
> +       test "$(cat file)" = "modified again"
> +'

With the addition of these three new tests, aside from the
introductory 'test_{un}config', this exact sequence of commands is now
repeated four times in the script. Such repetition suggests that the
common code should be moved to a function. For instance:

    test_rebase_autostash () {
        git reset --hard before-rebase &&
        echo dirty >new_file &&
        git add new_file &&
        git pull --rebase . copy &&
        test_cmp_rev HEAD^ copy &&
        test "$(cat new_file)" = dirty &&
        test "$(cat file)" = "modified again"
    }

And, a caller would look like this:

    test_expect_success 'pull ... rebase.autostash=true' '
        test_config rebase.autostash true &&
        test_rebase_autostash
    '

Of course, you'd also update the original test, from which this code
was copied, to also call the new function. Factoring out the common
code into a function should probably be done as a separate preparatory
patch.

This suggestion isn't mandatory and doesn't demand a re-roll, but, if
you're feeling ambitious, it would make the code easier to digest and
review.

> +test_expect_success 'pull --rebase --no-autostash & rebase.autostash=true' '
> +       test_config rebase.autostash true &&
> +       git reset --hard before-rebase &&
> +       echo dirty >new_file &&
> +       git add new_file &&
> +       test_must_fail git pull --rebase --no-autostash . copy 2>err &&
> +       test_i18ngrep "Cannot pull with rebase: Your index contains uncommitted changes." err

I don't care strongly, but many tests consider test_must_fail() alone
sufficient to verify proper behavior and don't bother being more exact
by checking the precise error message (since error messages sometimes
get refined, thus requiring adjustments to the tests). If you do
retain the error message check, it's often sufficient to check for
just a fragment of the error string rather than the full message. For
instance, it might be fine to grep merely for "uncommitted changes".

> +'
> +
> +test_expect_success 'pull --rebase --no-autostash & rebase.autostash=false' '
> +       test_config rebase.autostash false &&
> +       git reset --hard before-rebase &&
> +       echo dirty >new_file &&
> +       git add new_file &&
> +       test_must_fail git pull --rebase --no-autostash . copy 2>err &&
> +       test_i18ngrep "Cannot pull with rebase: Your index contains uncommitted changes." err
> +'
> +
> +test_expect_success 'pull --rebase --no-autostash & rebase.autostash unset' '

Same comment as above:

    test_unconfig rebase.autostash &&

> +       git reset --hard before-rebase &&
> +       echo dirty >new_file &&
> +       git add new_file &&
> +       test_must_fail git pull --rebase --no-autostash . copy 2>err &&
> +       test_i18ngrep "Cannot pull with rebase: Your index contains uncommitted changes." err
> +'

Same comment as above about the common code shared by these three new
test: moving it to a function is suggested.

> +test_expect_success 'pull --autostash (without --rebase) should error out' '
> +       test_must_fail git pull --autostash . copy 2>actual &&
> +       echo "fatal: --[no-]autostash option is only valid with --rebase." >expect &&
> +       test_i18ncmp actual expect

Same comment as above about checking the exact error message (vs. just
trusting test_must_fail).

Also, you mentioned in your cover letter that you couldn't use
test_i18ngrep because grep was mistaking "--[no-]autostash" in the
above expression as a command-line option. If you were using the exact
string as above as an argument to test_i18ngrep, then it is more
likely that the problem was that grep was seeing "[no-]" as a
character class rather than as a literal pattern to match. You could
get around this either by escaping the [ and ] with a backslash (\) or
by passing -F to test_i18ngrep.

Alternately, as mentioned above, just grep for a fragment of the error
message, such as "only valid with --rebase", rather than the full
diagnostic.

> +'
> +
> +test_expect_success 'pull --no-autostash (without --rebase) should error out' '
> +       test_must_fail git pull --no-autostash . copy 2>actual &&
> +       echo "fatal: --[no-]autostash option is only valid with --rebase." >expect &&
> +       test_i18ncmp actual expect
> +'

Same comment as above about code common to these two tests. However,
in this case, it might be easier simply to use a 'for' loop rather
than a function:

    for i in --autostash --no-autostash
    do
        test_expect_success "pull $i (without --rebase) is illegal" "
           test_must_fail git pull $i . copy 2>actual &&
           test_i18ngrep 'only valid with --rebase' actual
        "
    done

Take special note of how use of double (") and single (') quotes
differ in this case from other tests since $i needs to be interpolated
into the test body.

  reply	other threads:[~2016-03-25  8:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-21 18:18 [PATCH v10 0/2] introduce --[no-]autostash command line flag Mehul Jain
2016-03-21 18:18 ` [PATCH v10 1/2] git-pull.c: introduce git_pull_config() Mehul Jain
2016-03-21 18:18 ` [PATCH v10 2/2] pull --rebase: add --[no-]autostash flag Mehul Jain
2016-03-21 18:39   ` Matthieu Moy
2016-03-21 20:12 ` Mehul Jain
2016-03-25  8:31   ` Eric Sunshine [this message]
2016-03-25  8:44     ` Eric Sunshine
2016-03-25 16:37       ` Eric Sunshine
2016-03-25 18:07     ` Mehul Jain
2016-03-25 22:29       ` Eric Sunshine
2016-03-25  9:05   ` Matthieu Moy
2016-03-25 18:10     ` Mehul Jain
2016-03-25 18:37       ` Matthieu Moy
2016-03-25 19:07         ` Mehul Jain
2016-03-25  7:23 ` [PATCH v10 0/2] introduce --[no-]autostash command line flag Eric Sunshine
2016-03-25 18:01   ` Mehul Jain

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+cSdegoGNCMBMcHyEYiE+LUzixvdk-qu0Q-zbFvatX2=KA@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mehul.jain2029@gmail.com \
    --cc=pyokagan@gmail.com \
    /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).