Home/ Questions/Q 8193523
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T04:30:26+00:00

I am trying to use a pre-commit hook for Git. The hook looks like

  • 0

I am trying to use a pre-commit hook for Git. The hook looks like the following:

#!/bin/bash
echo "fail"
exit 1

Thus, it will always fail, i.e. my Git commit should fail.

If I add something with git and then commit it in the commandline I nicely get a fail and my commit fails.

But if I commit with NetBeans, my pre-commit hook does not get executed. It simply seems to ignore it.

I am using Ubuntu and NetBeans 7.1. The permissions for the pre-commit hook are -rwxrwxrwx (just changed it to 777 for testing purposes).

How is this possible?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It looks like that. Yes.

    If you look at the NetBeans Git Integration Plan, you’ll notice that there’s no support for hooks planned at all.

    Apart of this, I wouldn’t rely on any IDE integration of Git but use the command line. What if you decide to drop NetBeans tomorrow and use Eclipse instead? Or Visual Studio? Or KDevelop? You’ll have to learn a new IDE and again the integration of Git in the IDE. And you must hope that the developers of the IDE plugin did really implement that subset of Git that you need. It is a waste of time.

    Furthermore, the implementation of Git in NetBeans is far from complete. The features named as nice-to-have (stash, cherry-pick, rebase) are super-useful. Other killer features aren’t even mentioned (git bisect anyone?).

    Take the command line. Learn to use Git with it. Save your time.

    Looking at M2 of the NetBeans Git Integration Plan, one could see that the targeted backend for Git shall not be a native (i.e. platform specific) implementation of Git but jgit. That’s a totally braindead approach. Nearly every platform that you’re going to develop with has a native implementation of Git. The JNI exists. Why not take the platform specific binaries (that are surely better tested than a pure from-scratch Java implementation of the commands), put a small JNI wrapper around and you’re done? Yes, you’re going to lose write-once-run-everywhere, but stability and code quality would grow.

    • 0