All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Diamand <luke@diamand.org>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: bin chen <chenbin.sh@gmail.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/1] add hook pre-p4-submit
Date: Thu, 26 Jul 2018 22:09:13 +0100	[thread overview]
Message-ID: <CAE5ih7-DatojdaOYZSEKfgG+FeR9+CWiEcf0veHfz89W7Vhx=Q@mail.gmail.com> (raw)
In-Reply-To: <CAPig+cQ80DrYJjYgJEvfcpeNEscgNBvj7ydwxMMVRf6kBfpaqQ@mail.gmail.com>

On 26 July 2018 at 10:21, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Wed, Jul 25, 2018 at 10:08 PM chen bin <chenbin.sh@gmail.com> wrote:
>> The hook does not receive any information or input from git. The
>> original requirement
>> comes from my colleague. He want to run unit test automatically before
>> submitting code
>> to remote repository. Or else CI server will send the blame mail to the manager.
>
> Okay, that seems in line with a hook such as pre-commit. Please do
> update the documentation to mention that the hook takes no arguments
> and nothing on standard input, and perhaps describe in the
> documentation an example use-case (as you did here).
>
> I'm not a p4 or git-p4 user, but, out of curiosity, would there be any
> information which could be supplied to the hook as arguments or
> standard input (or both) which would help the hook author implement
> the hook more easily? Perhaps such information would be fodder for a
> future enhancement (not necessarily needed for this patch).


I tried to think of a use-case for a hook requiring any more
information, but I can't think of any. You're already chdir()'d to the
P4 shadow repo which is what you really need.

Anything where you just need the commit hash (e.g. checking the commit
message) can already be done with one of the existing git hooks; I
don't think git-p4 needs to duplicate that.

And we can't write a commit hook that can know about the Perforce
changelist, because we don't know what it is yet.

However, looking at the code, it runs the hook at the point just
*before* the changes are applied to the P4 shadow repo. Would it make
more sense to run the hook *after* they have been applied (but before
being P4 submitted) ?

That way you can run your tests on the checked-out P4 shadow directory
with your changes - as it stands, you can only run them on your git
repo at this point, which might not be in sync with Perforce (and
could be quite a long way out in fact).

Luke


>
>> The hook actually stops the submit process from start instead of abort
>> submit in midway.
>> So nothing is touched when hook exits with status 1.
>
> This might be a good thing to add to the documentation, as well.
>
>> I'm not sure whether `git-p4` should print some "hook rejection" message.
>> Current implementation is same as other hooks (`pre-commit`, for example).
>> Only hook itself is responsible to print error messages.
>>
>> Personally I don't have opinion whether we should print out hook
>> related message inside
>> `git-p4.py`. I just try to following existing convention of git.
>>
>> What you guys think?
>
> Following existing practice makes sense. It can always be revisited
> later if needed.
>
> Thanks.

  reply	other threads:[~2018-07-26 21:09 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE5ih7-DatojdaOYZSEKfgG+FeR9+CWiEcf0veHfz89W7Vhx=Q@mail.gmail.com' \
    --to=luke@diamand.org \
    --cc=chenbin.sh@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.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.
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.