Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] git hooks for [e|j]git
Laurent,
 
regarding collaboration: I will be busy next two weeks, so if you are in harry, just go ahead.
 
Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov
 
 
Gesendet: Freitag, 17. Oktober 2014 um 10:25 Uhr
Von: "Laurent Goubet" <laurent.goubet@xxxxxxx>
An: jgit-dev@xxxxxxxxxxx
Betreff: Re: [jgit-dev] git hooks for [e|j]git
Hi Andrey, Team,

We are also interested at Obeo about this support for the git hooks, and we'd also be interested to contribute this into E|JGit .

We also think that the "simplest possible" solution outlined here would be sufficient for most cases... since implementing something more complex would involve unreliable solutions : the hooks must be defined "per repository"; so they must be somehow read directly from the repository. If we implemented them in Java so that EGit and JGit can have their own hooks API, we'll need to involve class loaders and that too often proves too bug-prone for too litle gain. Reading and executing the hooks as cgit does seems like the most reliable solution, even if not the most portable.

As I gather, there are currently 12 client-side hooks available to command line users :
  • pre-commit
  • prepare-commit-msg
  • commit-msg
  • post-commit
  • post-rewrite
  • applypatch-msg
  • pre-applypatch
  • post-applypatch
  • pre-rebase
  • post-checkout
  • post-merge
  • pre-auto-gc

They're named with these hard-coded strings as their file name and are set as executable, and located in the <git repo>/.git/hooks folder. Only one of each is allowed (though that "one" can be specifically designed to chain others). They can be written in just about any language available on the user machine.

These work well on linux but will fail on windows, unless executed through msysgit or a unix-emulator such as cygwin... I think that having the same limitation in E|JGit is not really an issue. The implementation should probably use FS#runInShell(...) instead of Runtime.exec(...) to make use of cygwin when detected though.

Andrey didn't receive any answer to his proposal to contribute last month. Should we implement that proposal and push a patch to gerrit? Andrey, would you be interested in splitting the effort somehow?

Laurent Goubet
Obeo
 
On 16/10/2014 16:10, Andrey Loskutov wrote:
Hi,

We at Advantest see the need of adding pre-commit/pre-receive etc hooks to [e|j]git so that egit UI behavior "matches" CLI git behavior as defined in [1].

I think I found related bug [2] and asked there what the smallest possible implementation should do, but so far no one responded. Therefore I would like to ask same question here again.

Is support for pre-/post- etc hooks on anyone plan for [e|j]git 3.6? 
If not, does it make sense to add it to?

I'm offering to contribute simplest possible "Runtime.exec()" based solution which would "just work", but I would like to know what is the common agreement on the requested functionality.

IMHO the smallest possible implementation would need:

 * somehow read all the available hooks
 * run the appropriate git hook before/after appropriate jgit command using "Runtime.exec()" or platform-dependent "execution" API hook (similat to FS hooks)
 * allow to have egit UI callbacks for prompting/displaying hook output etc

Anything I'm missing here (for the *basic* feature set)?

[1] https://www.kernel.org/pub/software/scm/git/docs/githooks.html
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=299315

Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov
_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jgit-dev

Back to the top