Re: Git Hooks

2017-12-16 Thread Jeff King
On Fri, Dec 15, 2017 at 12:48:07PM -0800, Satyakiran Duggina wrote: > To give the code pullers a chance to review, can we not have a > `trusted-hooks: default` and `trusted-SHA: ` field in .git/. > I'm assuming githooks/ are source tracked here. > > When developer tries to execute `git commit`,

Re: Git Hooks

2017-12-15 Thread Satyakiran Duggina
Thanks, Bryan. To give the code pullers a chance to review, can we not have a `trusted-hooks: default` and `trusted-SHA: ` field in .git/. I'm assuming githooks/ are source tracked here. When developer tries to execute `git commit`, git can ask developer to change `trusted-hooks` field to true

Re: Git Hooks

2017-12-15 Thread Bryan Turner
On Fri, Dec 15, 2017 at 11:12 AM, Satyakiran Duggina wrote: > I see that `git init` creates a .git directory and hooks are to be > placed in that directory and these hooks are not tracked by version > control. To achieve tracked hooks, either each developer has to copy > the

Git Hooks

2017-12-15 Thread Satyakiran Duggina
I see that `git init` creates a .git directory and hooks are to be placed in that directory and these hooks are not tracked by version control. To achieve tracked hooks, either each developer has to copy the hooks or use tools like overcommit, pre-commit, husky etc. I'm wondering why hooks are

Re: Security of .git/config and .git/hooks

2017-10-03 Thread Stefan Beller
So once upon a time we compared Gits security model with a web browser. A web browser lets you execute 3rd party code (e.g. javascript) and it is supposedly safe to look at malicious sites. Currently Git only promises to have the clone/fetch operation safe, not the "here is a zip of my whole

Re: Security of .git/config and .git/hooks

2017-10-03 Thread Jeff King
main difference is that the profile inclusion is done by path rather than riding along with the repository directory if it gets moved. In practice I doubt that matters much, and I think the security model for include.gitdir is a lot simpler. > 3. Likewise for hooks: my ~/.config/git/hooks/

Re: Security of .git/config and .git/hooks

2017-10-03 Thread Christian Couder
Hi, On Tue, Oct 3, 2017 at 1:45 AM, Jonathan Nieder wrote: > Proposed fix: because of case (1), I would like a way to tell Git to > stop trusting any files in .git. That is: > > 1. Introduce a (configurable) list of "safe" configuration items that > can be set in

Re: Security of .git/config and .git/hooks

2017-10-02 Thread Junio C Hamano
acker. Meaning, "include" is not in "safe" category, but a value that begins with "~/.config/git/" are excempt??? > 3. Likewise for hooks: my ~/.config/git/hooks/ directory would > contain hooks for repositories to make use of. Repositories could >

Security of .git/config and .git/hooks

2017-10-02 Thread Jonathan Nieder
ated: 1. I put my repository in a zip file and ask a Git expert to help me recover data from it, or 2. My repository is in a shared directory on NFS. Unless the administrator setting that up is very careful, it is likely that the least privileged user with write access to .git

Re: [PATCH] respect core.hooksPath, falling back to .git/hooks

2017-06-14 Thread Johannes Schindelin
t of love. Something along the lines: Since v2.9.0, Git knows about the config variable core.hookspath that allows overriding the path to the directory containing the Git hooks. Since v2.10.0, the `--git-path` option respects that config variable, too, so we

Re: [PATCH] respect core.hooksPath, falling back to .git/hooks

2017-06-02 Thread Philipp Gortan
Dear Philip, the previous mail contains a patch against the master of http://repo.or.cz/git-gui.git Could you please review it? I am not a TCL developer, so please take extra care! Thanks, Philipp signature.asc Description: OpenPGP digital signature

[PATCH] respect core.hooksPath, falling back to .git/hooks

2017-06-02 Thread Philipp Gortan
Signed-off-by: Philipp Gortan --- The following patch tries to fix git-gui to respect the core.hooksPath config variable, falling back to the old behavior. git-gui.sh | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/git-gui.sh b/git-gui.sh index

Re: Additional git hooks

2016-12-15 Thread Jeff King
On Thu, Dec 15, 2016 at 09:14:30AM -0500, Jeff King wrote: > On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote: > > > Would patches introducing new git hooks, e.g. for post-fetch, be > > eligible for acceptance? > > The general guidelines for addin

Re: Additional git hooks

2016-12-15 Thread Jeff King
On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote: > Would patches introducing new git hooks, e.g. for post-fetch, be > eligible for acceptance? The general guidelines for adding hooks is laid out here: http://public-inbox.org/git/7vbq7ibxhh@gitster.siamese.dynd

Additional git hooks

2016-12-15 Thread Chiel ten Brinke
Would patches introducing new git hooks, e.g. for post-fetch, be eligible for acceptance? If a more detailed explanation about a specific use case is required, I'd be happy to provide it. Btw, the link in the README http://news.gmane.org/gmane.comp.version-control.git/ is dead. Chiel

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-26 Thread Junio C Hamano
Ævar Arnfjörð Bjarmason writes: > I think it's fair enough to say that if we had this facility this > would be good enough: > > * Your hooks are executed in glob() order, local .git first, then > /etc/git/... > > * If it's a hook like pre-commit that can reject something the

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-26 Thread Marc Branchaud
On 2016-04-26 12:09 PM, Ævar Arnfjörð Bjarmason wrote: Basically you can look at patches to a project on a spectrum of: 1. You hacked something up locally 2. It's in someone's *.git repo as a POC 3. It's a third-party patch series used by a bunch of people 4. In an official release but

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-26 Thread Christian Couder
On Tue, Apr 26, 2016 at 6:09 PM, Ævar Arnfjörð Bjarmason wrote: > On Tue, Apr 26, 2016 at 3:40 PM, Marc Branchaud wrote: >> On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote: >>> >>> Makes sense to have an experimental.* config tree for git for stuff

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-26 Thread Ævar Arnfjörð Bjarmason
On Tue, Apr 26, 2016 at 3:40 PM, Marc Branchaud wrote: > On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote: >> >> Makes sense to have an experimental.* config tree for git for stuff like >> this. > > I disagree. > > * If the point is to express some kind of warning to

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-26 Thread Marc Branchaud
On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote: > > Makes sense to have an experimental.* config tree for git for stuff like this. I disagree. * If the point is to express some kind of warning to users, I think the community has been much better served by leaving experimental settings

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-26 Thread Ævar Arnfjörð Bjarmason
On Mon, Apr 25, 2016 at 7:45 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> The reason for supporting the *.d directories was that I spotted a lot >> of hooks people had hacked up at work using the pee(1) command[1] to >> run sequences of

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-25 Thread Junio C Hamano
Ævar Arnfjörð Bjarmason writes: > The reason for supporting the *.d directories was that I spotted a lot > of hooks people had hacked up at work using the pee(1) command[1] to > run sequences of other unrelated hook commands. IIRC, we wanted to do this several years ago but

RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

2016-04-22 Thread Ævar Arnfjörð Bjarmason
On Sat, Apr 23, 2016 at 1:33 AM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > Change the hardcoded lookup for .git/hooks/* to optionally lookup in > $(git config core.hooksDirectory)/* instead if that config key is set. I think this'll do for my use-case, but I started with a

Re: [bug] .git/hooks/commit-msg.sample test is reversed

2015-09-15 Thread Matthieu Moy
Federico Fissore writes: > Hello everyone > > In file commit-msg.sample, grep test is reversed. It greps > '^Signed-off-by: ' > while it should grep > 'Signed-off-by: ' > > If you run the sample against attached file, it won't complain. Remove > the ^ and it will work as

[bug] .git/hooks/commit-msg.sample test is reversed

2015-09-15 Thread Federico Fissore
Hello everyone In file commit-msg.sample, grep test is reversed. It greps '^Signed-off-by: ' while it should grep 'Signed-off-by: ' If you run the sample against attached file, it won't complain. Remove the ^ and it will work as expected Regards Federico Commit message

git hooks and environment variables

2015-07-23 Thread Jacob Keller
I've noticed that not all hooks have all of the environment variables set when they are run, and it is not clear from the manual pages which hooks have which variables set on the command line. Specifically, they don't all have GIT_DIR set, I haven't taken the time to verify exactly which variables

Re: Feature Request: provide cmdline args to git hooks

2015-04-15 Thread Junio C Hamano
dst $ cd src $ echo (date;cat) pushlog .git/hooks/pre-push $ chmod +x .git/hooks/pre-push $ git commit -m 'initial' --allow-empty $ git tag -m 'initial' initial Push only the branch: $ GIT_TRACE_PACKET=1 git push ../dst master 21 | grep 'push' 11:07:26 packet: push

Re: Feature Request: provide cmdline args to git hooks

2015-04-14 Thread Junio C Hamano
Chris O'Kelly ch...@mapcreative.com.au writes: A brief background of my use case: I am wanting to write a pre-push hook to prevent tags being pushed to our production servers. The production servers in our case are --bare endpoints, and when we push a tag at them, they always checkout the

Re: Feature Request: provide cmdline args to git hooks

2015-04-14 Thread Junio C Hamano
Chris O'Kelly ch...@mapcreative.com.au writes: [administrivia: people read from top to bottom; please do not top post] On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano gits...@pobox.com wrote: Chris O'Kelly ch...@mapcreative.com.au writes: A brief background of my use case: I am wanting to

Re: Feature Request: provide cmdline args to git hooks

2015-04-14 Thread Chris O'Kelly
I do not offhand know (I am on a bus with terrible connection so I won't bother checking the source now) if we send this ref has to point at that object even for STATUS_UPTODATE cases, to cause your remote to trigger the receive hook in the frist place, but if that is the case, then the code

Re: Feature Request: provide cmdline args to git hooks

2015-04-14 Thread Chris O'Kelly
Unfortunately in this case we don't have control over the hooks at the receiving end - we want to prevent tags from being pushed by all users to these repo's. On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano gits...@pobox.com wrote: Chris O'Kelly ch...@mapcreative.com.au writes: A brief

Feature Request: provide cmdline args to git hooks

2015-04-13 Thread Chris O'Kelly
Hello, Just a brief note about a feature I would find incredibly useful, were it available. A brief background of my use case: I am wanting to write a pre-push hook to prevent tags being pushed to our production servers. The production servers in our case are --bare endpoints, and when we push a

Re: Adding git hooks

2014-04-28 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote: Suvorov Ivan sv...@inbox.ru writes: I want to extend the functionality of git due to the possibility of separation of the user repository into 2 parts - one part will be stored as usual,

Re: Adding git hooks

2014-04-28 Thread Jeff King
On Mon, Apr 28, 2014 at 09:43:10AM -0700, Junio C Hamano wrote: Yes, I'd love to see something along that line in the longer term, showing all the objects as just regular objects under the hood, with implementation details hidden in the object layer (just like there is no distinction between

Adding git hooks

2014-04-26 Thread Suvorov Ivan
Hello. I want to extend the functionality of git due to the possibility of separation of the user repository into 2 parts - one part will be stored as usual, under version control git, and the second part will be stored in another location such as an FTP-server. This will be done in order to

Re: Adding git hooks

2014-04-26 Thread Junio C Hamano
Suvorov Ivan sv...@inbox.ru writes: I want to extend the functionality of git due to the possibility of separation of the user repository into 2 parts - one part will be stored as usual, under version control git, and the second part will be stored in another location such as an FTP-server.

Re: Adding git hooks

2014-04-26 Thread Jeff King
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote: Suvorov Ivan sv...@inbox.ru writes: I want to extend the functionality of git due to the possibility of separation of the user repository into 2 parts - one part will be stored as usual, under version control git, and the

Re: Git-hooks pre-push script does not receive input on stdin

2014-03-23 Thread Torsten Bögershausen
On 2014-03-23 01.44, David Cowden wrote: http://stackoverflow.com/questions/22585091/git-hooks-pre-push-script-does-not-receive-input-via-stdin Is this a bug in git? Or am I just a shell noob? Thanks in advance, David I assume that you have the right version of Git ? You can look

Re: Git-hooks pre-push script does not receive input on stdin

2014-03-23 Thread David Cowden
://stackoverflow.com/questions/22585091/git-hooks-pre-push-script-does-not-receive-input-via-stdin Is this a bug in git? Or am I just a shell noob? Thanks in advance, David I assume that you have the right version of Git ? You can look into the source of Git, to be more exact the test suite

Git-hooks pre-push script does not receive input on stdin

2014-03-22 Thread David Cowden
http://stackoverflow.com/questions/22585091/git-hooks-pre-push-script-does-not-receive-input-via-stdin Is this a bug in git? Or am I just a shell noob? Thanks in advance, David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org

Re: GIT Hooks and security

2013-10-26 Thread Olivier Revollat
Very helpful :) thanks ! 2013/10/26 Bryan Turner btur...@atlassian.com: No, the .git/hooks directory in your clone is created from your local templates, installed with your Git distribution, not the remote hooks. On Linux distributions, these templates are often in someplace like /usr/share

Re: GIT Hooks and security

2013-10-26 Thread Ondřej Bílka
2013/10/26 Bryan Turner btur...@atlassian.com: No, the .git/hooks directory in your clone is created from your local templates, installed with your Git distribution, not the remote hooks. On Linux distributions, these templates are often in someplace like /usr/share/git-core/templates

GIT Hooks and security

2013-10-25 Thread Olivier Revollat
I was wondering : What if I had a malicious GIT repository who can inject code via git hooks mechanism : someone clone my repo and some malicious code is executed when a certain GIT hook is triggered (for example on commit (prepare-commit-msg' hook)) ? What if I email /etc/passwd for exemple

Re: GIT Hooks and security

2013-10-25 Thread Junio C Hamano
Olivier Revollat revol...@gmail.com writes: I was wondering : What if I had a malicious GIT repository who can inject code via git hooks mechanism : someone clone my repo and some malicious code is executed when a certain GIT hook is triggered (for example on commit (prepare-commit-msg' hook

Re: GIT Hooks and security

2013-10-25 Thread Bryan Turner
No, the .git/hooks directory in your clone is created from your local templates, installed with your Git distribution, not the remote hooks. On Linux distributions, these templates are often in someplace like /usr/share/git-core/templates (for normal packages), and on Windows with msysgit