public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Heiko Voigt <git-list@hvoigt•net>
To: Thomas Rast <trast@student•ethz.ch>
Cc: Wincent Colaiuta <win@wincent•com>, git@vger•kernel.org
Subject: Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit
Date: Sat, 21 Feb 2009 14:31:01 +0100	[thread overview]
Message-ID: <49A00215.9070106@hvoigt.net> (raw)
In-Reply-To: <200902211216.43964.trast@student.ethz.ch>

Thomas Rast schrieb:
> Heiko Voigt wrote:
>> This leads me to a completely different solution to the same problem.
>> How about teaching git to inherit its hooks from the parental project
>> (e.g. the one it was cloned from)? That way we are not limited to
>> one default behaviour but many that would match the one from the
>> upstream project.
> [...]
>> What do you think about that?
> 
> Three words: huge security hole.
> 
> Especially on cloning, where the checkout immediately afterwards
> would already run the post-checkout hook, without any chance for the
> user to inspect its contents.

Good point here as well. 

> The usual advice is to track the hooks in the repository, e.g., under
> hooks/, and instruct the users to copy them to .git/hooks/ if they
> want them.

I read about that possibility but it does not completely satisfy me,
because a new user to a project can not just 

   git clone url/to/somewhere

and start working.

How about combining my first approach with the second idea? Teach git
different default sets of hooks. So something like:

   git init --workflow="topic-branches"

would initialize and install a certain set of hooks.

Implement the possibility to propagate this setting to the server, by
using a config variable or similar. This way only secure hooks will
automatically be inherited and the user has the benefit of a more
specific workflow support.

cheers Heiko

  reply	other threads:[~2009-02-21 13:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-20 18:13 [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit Heiko Voigt
2009-02-20 20:49 ` Wincent Colaiuta
2009-02-21 10:56   ` Heiko Voigt
2009-02-21 11:16     ` Thomas Rast
2009-02-21 13:31       ` Heiko Voigt [this message]
2009-02-21 14:05         ` Jakub Narebski
2009-02-21 14:30           ` Heiko Voigt
2009-02-23 18:41         ` Heiko Voigt
2009-10-19  8:50 ` Junio C Hamano
2009-10-20 19:59   ` Heiko Voigt

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=49A00215.9070106@hvoigt.net \
    --to=git-list@hvoigt$(echo .)net \
    --cc=git@vger$(echo .)kernel.org \
    --cc=trast@student$(echo .)ethz.ch \
    --cc=win@wincent$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox