git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Scott Chacon" <schacon@gmail.com>
Cc: "Jeff King" <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH] add a 'pre-push' hook
Date: Tue, 19 Aug 2008 12:39:07 -0700	[thread overview]
Message-ID: <7v63pw3ick.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <d411cc4a0808191200o39837fd0ka2530aed870e06b0@mail.gmail.com> (Scott Chacon's message of "Tue, 19 Aug 2008 12:00:38 -0700")

"Scott Chacon" <schacon@gmail.com> writes:

> If the patch is acceptable, I will update the githooks doc with more
> information, but we would like this so that you could add a hook that
> runs your automated tests before a push would go through.

I've said this number of times on this list but I guess it has been while
since the last time I said it.

"If the patch is acceptable, I'll document it" is the last thing we as
reviewers would want to hear from the submitter, *unless* there is an
ongoing discussion that already have established what is wanted and a
patch came as "ok, here is a possible solution, what do you guys think?".

If the original submitter does not care enough to defend why it is needed,
why should reviewers spend their precious brain cycles to decipher what it
does, guess what situation the change would help, and determine if the
change actually would help the situation it might be trying to help (and
risk wasting all this work because they guessed the motivation wrong)?
And what assurance would we have that the change will be maintained and
supported?

Having said that, I would agree "validate and potentially stop before
pushing" is a very good thing to have.

It is still unclear at this point what kind of input that validation would
want to base its decision on.  At least we would want what branch is being
pushed (so that a validation failure on a branch that is not being pushed
would not interfere), and possibly where you are pushing to (so that you
can still push a change you would want to verify and potentially polish on
a different test/dev box without getting interfered).

  parent reply	other threads:[~2008-08-19 19:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1219170876-46893-1-git-send-email-schacon@gmail.com>
2008-08-19 18:55 ` [PATCH] add a 'pre-push' hook Scott Chacon
2008-08-19 18:58   ` Jeff King
2008-08-19 19:00     ` Scott Chacon
2008-08-19 19:08       ` Jeff King
2008-08-19 19:59         ` Shawn O. Pearce
2008-08-19 20:26           ` Scott Chacon
2008-08-19 21:26           ` しらいしななこ
2008-08-19 21:45             ` Scott Chacon
2008-08-19 22:23               ` Junio C Hamano
2008-08-19 22:26         ` Sam Vilain
2008-08-20  0:15           ` Jeff King
2008-08-19 19:39       ` Junio C Hamano [this message]
2008-08-19 19:58         ` Scott Chacon
2008-08-19 23:35           ` Junio C Hamano
2008-08-19 23:39             ` Shawn O. Pearce

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=7v63pw3ick.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=schacon@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).