|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I must respectfully say that I find the argument for JGit over CLI Git very unconvincing.
I've no evidence whatsoever of CLI Git causing issues, yet this page is full of users for which JGit broke everything.
Arguments that "using an external process introduce[s] some major issues" are particularly unconvincing. Jenkins is a CI system. That means that its core role is to invoke external processes and integrate them. Any plugin should be able to invoke external processes and deal with their output. That's the core job of a plug-in.
Statements like "I guess it's stable enough…" are also a cause for concern. This is my CI system: I don't want guessing, I want solid code, such as just calling CLI Git.
CLI Git gets a huge amount of oversight and testing. It's rock solid. It's become clear that JGit is nowhere near as well-tested or as solid, and frankly it has lost my trust.
More importantly, I want confidence that Jenkins is using the exact same tools that I would use if building manually.
No-one in their right mind would think of re-implementing gcc or Clang/LLVM in Java, so why re-implement CLI Git?