git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: chenbin.sh@gmail.com
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/1] add hook pre-p4-submit
Date: Wed, 25 Jul 2018 16:00:23 -0400	[thread overview]
Message-ID: <CAPig+cR2gYEwOTVBMRde35rn9oVsixeerbm5iJV+FmnOiBWxqQ@mail.gmail.com> (raw)
In-Reply-To: <20180725134345.8631-1-chenbin.sh@gmail.com>

On Wed, Jul 25, 2018 at 9:45 AM Chen Bin <chenbin.sh@gmail.com> wrote:
> Hook pre-p4-submit is executed before git-p4 actually submits code.
> If the hook exits with non-zero value, submit process will abort.

Bikeshedding: Should this be named 'p4-pre-submit'? That way, if
git-p4 ever grows additional hooks, they can all be grouped under the
"p4-" prefix.

More below...

> Signed-off-by: Chen Bin <chenbin.sh@gmail.com>
> ---
> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
> @@ -374,6 +374,13 @@ These options can be used to modify 'git p4 submit' behavior.
> +Hook for submit
> +~~~~~~~~~~~~~~~
> +Hook `pre-p4-submit` is executed if it exists and is executable.
> +Exiting with non-zero status from this script cause `git-p4 submit` to abort.
> +By default the hooks directory is `$GIT_DIR/hooks`, but that can be changed.

Does the hook receive any arguments? Does it receive anything on its
standard input? Those questions ought to be answered by the
documentation.

Also, how is the hook supposed to determine whether the "submit"
should proceed? How does it know what is being submitted? Perhaps the
documentation could provide some explanation of how the hook should
glean such information (especially if the hook does not itself receive
any input).

> diff --git a/git-p4.py b/git-p4.py
> +        # locate hook
> +        hooks_path = gitConfig("core.hooksPath")
> +        if len(hooks_path) > 0:
> +            hook_file = os.path.join(hooks_path, "pre-p4-submit")
> +        else:
> +            hook_file = os.path.join(read_pipe("git rev-parse --git-dir").strip(), "hooks", "pre-p4-submit")
> +
> +        # Execute hook. If it exits with non-zero value, do NOT continue.
> +        if os.path.isfile(hook_file) and os.access(hook_file, os.X_OK) and subprocess.call([hook_file]) != 0:
> +            sys.exit(1)

Nit: The two #comments merely repeat what the code itself already says
clearly enough, thus don't add value (so can be dropped).

Should this be emitting some sort of message letting the user know
that the operation was aborted due to the hook's "rejection"? That
could be especially important if the hook itself is silent (or buggy).

> diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
> @@ -261,6 +261,28 @@ test_expect_success 'unresolvable host in P4PORT should display error' '
> +# Test following scenarios:
> +#   - Without hook ".git/hooks/pre-p4-submit", submit should continue
> +#   - With hook returning 0, submit should continue
> +#   - With hook returning 1, submit should abort

Testing three separate cases would normally be done with three
separate tests, making it easier to figure out which case failed. But,
perhaps it doesn't matter here.

> +test_expect_success 'run hook pre-p4-submit before submit' '
> +       test_when_finished cleanup_git &&
> +       git p4 clone --dest="$git" //depot &&
> +       (
> +               cd "$git" &&
> +               echo "hello world" >hello.txt &&
> +               git add hello.txt &&
> +               git commit -m "add hello.txt" &&
> +               git config git-p4.skipSubmitEdit true &&

The wholesale removal of the $git directory by cleanup_git() when the
test finishes is undoing this config setting. Ditto regarding the
hooks created below. Okay.

> +               git p4 submit --dry-run | grep "Would apply" &&

We normally don't use a git command upstream in a pipe since the exit
code of that command gets lost (so, if it crashes, we don't know about
it). Instead:

    git p4 submit --dry-run >out &&
    grep "Would apply" out &&

Also, if "Would apply" is localized, we'd use test_i18ngrep (but you
don't need it in this case).

> +               mkdir -p .git/hooks &&
> +               : >.git/hooks/pre-p4-submit && chmod +x .git/hooks/pre-p4-submit &&

It might be clearer to readers of this test to use an explicit "exit
0" here (complementing the "exit 1" below). The current asymmetry
required extra cognitive effort to realize that this is the "returning
0" case mentioned in the comment above the test.

> +               git p4 submit --dry-run | grep "Would apply" &&
> +               echo #!/bin/sh && echo exit 1 >.git/hooks/pre-p4-submit &&

Use write_script() for this, which takes care of the #!/bin/sh line
and doing chmod:

    write_script >.git/hooks/pre-p4-submit <<-\EOF &&
    exit 1
    EOF

> +               git p4 submit --dry-run | grep "Would apply" || echo "Abort submit"

More idiomatic in this test suite:

    git p4 submit --dry-run >out &&
    ! grep "Would apply" out

> +       )
> +'

  reply	other threads:[~2018-07-25 20:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-23 11:27 [PATCH 1/1] add hook pre-p4-submit Chen Bin
2018-07-25  8:37 ` Luke Diamand
2018-07-25  9:14   ` Ævar Arnfjörð Bjarmason
2018-07-25 11:10     ` chen bin
2018-07-25 13:43   ` Chen Bin
2018-07-25 20:00     ` Eric Sunshine [this message]
2018-07-25 20:21       ` Junio C Hamano
2018-07-26  2:08       ` chen bin
2018-07-26  9:21         ` Eric Sunshine
2018-07-26 21:09           ` Luke Diamand
2018-07-27  1:31             ` chen bin
2018-07-26 13:41     ` Chen Bin
2018-07-26 16:49       ` Junio C Hamano
2018-07-26 21:20         ` Eric Sunshine
2018-07-27 11:22         ` [PATCH 1/1] Add the `p4-pre-submit` hook Chen Bin
2018-07-27 18:15           ` Eric Sunshine
2018-07-30 18:07           ` Junio C Hamano
2018-07-30 18:48             ` Luke Diamand
2018-07-30 21:01               ` Junio C Hamano
2018-07-31  8:46           ` SZEDER Gábor
2018-07-31 13:40             ` Luke Diamand
2018-07-31 14:40               ` Junio C Hamano
2018-07-31 19:54                 ` Luke Diamand
2018-08-01 14:57                   ` chen bin
2018-08-01 15:10                     ` Junio C Hamano
2018-08-01 15:54                       ` Chen Bin
2018-08-01 17:41                         ` 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+cR2gYEwOTVBMRde35rn9oVsixeerbm5iJV+FmnOiBWxqQ@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=chenbin.sh@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).