eclipse-jgit / jgit Goto Github PK
View Code? Open in Web Editor NEWJGit, the Java implementation of git
Home Page: https://www.eclipse.org/jgit/
License: Other
JGit, the Java implementation of git
Home Page: https://www.eclipse.org/jgit/
License: Other
I have a need to repack a git repo after it has been closed down. This is due to some of the pack files being over 1gb in size and causing our systems to run out of memory as a result. While locally I can achieve this by doing git repack --max-pack-size=100m -Ad
, our production systems do not have git installed so no dropping down to shell environment is allowed. The jgit library is the only means I have to make this adjustment (unless there is an option with clone that I didn't find).
Thus I really need the ability to either repack the repo, or some kind of improved memory handling that causes it to not run out of memory in production when walking the tree of a pack that is really large.
It is a core bit of git functionality and would help prevent out of memory issues when working with poorly packed git repositories.
Locally I can use git repack --max-pack-size=100m -Ad
to work around the memory problems but in production that isn't really an option to run by hand as git is not installed. Only jgit can work with the code.
Perhaps a way to clone it with a max pack size? Unsure how that would work as I didn't see a way to do that via the git cli.
Although not explicitly listed in https://github.com/eclipse-jgit/jgit/blob/b1cc74b75b771279d81de15833da514c71513648/Documentation/config-options.md conditional includes are not supported yet by JGit. Those were added with Git 2.13
This is very useful if slightly different configs should be used for several repositories (sharing the same root folder). Compare with https://stackoverflow.com/questions/21307793/set-git-config-values-for-all-child-folders
The only workaround would be repository specific configurations which leads to a lot of config duplication and effort to initially set this correctly
No response
Windows
21 of the jgit wiki pages have this kind of bad newline:
No response
@msohn If you look into this, cloning the jgit wiki locally and pushing might be possible for you (I don't even have editing rights for single pages).
6.9.0.202403050737-r
Linux/Unix, MacOS, Windows
The jgit library produces invalid conflicts when using the "diff3" style. Consider the following example:
a
d
a
b
d
a
b
c
d
In other words, ours
deletes the b
line and theirs
keeps it but inserts the c
line after it.
The merged result is
a
<<<<<<< OURS
||||||| BASE
b
d
=======
b
c
>>>>>>> THEIRS
d
(note the incorrect inclusion of the d
in the base part of the conflict hunk, duplicating the d
outside of the conflict)
The merged result should be
a
<<<<<<< OURS
||||||| BASE
b
=======
b
c
>>>>>>> THEIRS
d
No response
No response
5.13.0 probably (the one used by tycho qualifier computer)
Linux/Unix
According to eclipse-pde/eclipse.pde#1020 (comment) , JGit seems to not properly unregister some services and that can cause further issue in systems that embed it, such as Tycho or Jenkins):
When using Tycho, in some circumstances Maven build fails with
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:09 min
[INFO] Finished at: 2024-01-30T08:06:00Z
[INFO] ------------------------------------------------------------------------
Error: Exception in thread "Thread-4" java.lang.NoClassDefFoundError: org/eclipse/jgit/internal/JGitText
at org.eclipse.jgit.internal.util.ShutdownHook.cleanup(ShutdownHook.java:85)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.lang.ClassNotFoundException: org.eclipse.jgit.internal.JGitText
... 2 more
No error.
No response
Some analysis of the problem here: eclipse-pde/eclipse.pde#1020 (comment)
All
Linux/Unix
jgit is still using an End of Community Support version of Jetty.
See:
Not possible to use the only supported version of Jetty at the moment.
Upgrade to Jetty 12.
Note: if you want to stick with the javax.servlet
namespace, then use the ee8
environment on Jetty 12.
No response
No response
I would like to be able to sign commits using an SSH key, which is possible since Git 2.34.0.
I use SSH key authentication for Git, which makes it natural to also want to use this for commit signing.
I am already doing this using the command line for GitHub (following this guide) and would like to do it using JGit too, mainly because I like to use Gitnuro, which uses JGit. There's an an issue over at Gitnuro for this too.
I have considered...
No response
Blobless clones are a suggested optimization to clone large repositories.
git clone --filter=blob:none <url>
The native Git CLI will lazy load blobs on-demand, but JGit simply fails:
$ ./org.eclipse.jgit.pgm-6.8.0.202311291450-r.sh blame build.gradle
fatal: Missing blob fc321990ffac88fc65d90d41c483db443833aa93
I am not sure this is a popular practice to use blobless clones on developer machines, so this is likely not a use case for EGit.
But for other use cases where JGit is used on CI/CD platforms (Jenkins, Maven, Sonar, ...) it would be great to support this feature.
The current alternative is to ask users to not use blobless clones, or to stop using JGit and use the native Git CLI.
https://community.sonarsource.com/t/missing-blob-jgit-error-with-sonarcloud/109574
https://community.sonarsource.com/t/scan-on-git-blobless-clone-failed/106038
6.9.0
Linux/Unix, MacOS
When a large repository with a lot of refs and activity is being, it can happen that the following error is being thrown:
Caused by: org.eclipse.jgit.transport.WantNotValidException: want 9784ba017f833fc41c1ad4344a75105ee69d639e not valid
at org.eclipse.jgit.transport.UploadPack$AdvertisedRequestValidator.checkWants(UploadPack.java:2002)
at org.eclipse.jgit.transport.UploadPack.parseWants(UploadPack.java:1953)
at org.eclipse.jgit.transport.UploadPack.processHaveLines(UploadPack.java:1827)
at org.eclipse.jgit.transport.UploadPack.fetchV2(UploadPack.java:1275)
at org.eclipse.jgit.transport.UploadPack.serveOneCommandV2(UploadPack.java:1389)
at org.eclipse.jgit.transport.UploadPack.serviceV2(UploadPack.java:1443)
at org.eclipse.jgit.transport.UploadPack.uploadWithExceptionPropagation(UploadPack.java:886)
at org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:796)
... 12 more
Initial research showed that this happens, if a wanted ref is being updated during the fetch. Looking at the code it seems that this change has to happen while the fetch spends time in UploadPack.fetchV2()
, between the computation of wantedIds and advertised IDs, which happens later. In that case both Sets differ from each other and validation fails.
This was observed in Gerrit for fetches in large repositories with wide refSpecs or for mirror clones.
Caused by: org.eclipse.jgit.transport.WantNotValidException: want 9784ba017f833fc41c1ad4344a75105ee69d639e not valid
at org.eclipse.jgit.transport.UploadPack$AdvertisedRequestValidator.checkWants(UploadPack.java:2002)
at org.eclipse.jgit.transport.UploadPack.parseWants(UploadPack.java:1953)
at org.eclipse.jgit.transport.UploadPack.processHaveLines(UploadPack.java:1827)
at org.eclipse.jgit.transport.UploadPack.fetchV2(UploadPack.java:1275)
at org.eclipse.jgit.transport.UploadPack.serveOneCommandV2(UploadPack.java:1389)
at org.eclipse.jgit.transport.UploadPack.serviceV2(UploadPack.java:1443)
at org.eclipse.jgit.transport.UploadPack.uploadWithExceptionPropagation(UploadPack.java:886)
at org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:796)
... 12 more
The fetch or mirror clone works and all objects are being transferred.
No response
No response
In many cases, users explicitly manage the JSPs that exist in their environment to meet various compliance related requirements that BouncyCastle
may not be able to fulfill (certain parts of FIPS-140, for example).
By forcibly adding bouncy castle as a provider on these lines, jgit breaks the ability of developers to control the JSPs in use, and thus are unable to meet some of these compliance requirements.
Rather than forcible addition of BouncyCastle as a provider, jgit
should instead check for a viable provider of the needed algorithms and use that (in most cases, BouncyCastle
will be available by default. If not available, an exception should be thrown.
Alternatively, an option could be added to the relevant constructor to disable this behavior for users that need to control their JSPs.
default
Linux/Unix
My Jenkins jobs such as https://ci.eclipse.org/qvtd/job/qvtd-master/607/console seem to terminate benignly with
Exception in thread "Thread-5" java.lang.NoClassDefFoundError: org/eclipse/jgit/internal/JGitText at org.eclipse.jgit.internal.util.ShutdownHook.cleanup(ShutdownHook.java:85) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: java.lang.ClassNotFoundException: org.eclipse.jgit.internal.JGitText ... 2 more Terminating xvnc. Recording test results
Others get similar: https://github.com/diffplug/spotless/runs/19353778487
see above
see above
see above
see above
6.8.0.202311291450-r
Linux/Unix
don't ask me how this is possible, I don't understand what github is doing to make this weird, even git isn't behaving like I'd expect, however github is checking it out though... build included for reference.
Here's the tag I push
git tag -m "v0.9.3" -a v0.9.3 -f && git push --tags -f
github does some weird checkout thing that I haven't yet repro-ed locally...
SemverExtension(@NonNull Supplier<@NonNull Git> git) {
this.git = Objects.requireNonNull(git);
}
Try<@Nullable String> describe() {
return Try.of(() -> this.git.get().describe().setMatch(VERSION_GLOB).setTags(true))
.mapTry(DescribeCommand::call)
.onFailure(ExceptionTools::rethrow);
}
public Semver getGradlePlugin() {
return describe()
.map(v -> null == v ? PRE_VERSION : v)
.map(Semver::coerce)
.map(
v ->
!(v.getPreRelease().isEmpty() || v.getBuild().isEmpty()) ? v.withClearedPreReleaseAndBuild().nextPatch() : v
)
.get();
}
git describe #v0.9.2-5-g8ed3c02
git describe --tags #v0.9.3
jgit
version: 0.9.2-5-g8ed3c02
should behave like git describe --tags
No response
https://github.com/xenoterracide/gradle-semver/actions/runs/8071119003/job/22050029061
the behavior is the same without this change
Hello,
Is it possible to make a plugin for Gradle ?
I would like to use JGit to manage my versions and my Git repository in the file "build.gradle.kts".
No response
No response
Orbit generates a report for JGit's target platform:
https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/jgit/REPORT.md
You can literally copy and paste this updated version:
https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/jgit/updated.target
to replace this version:
The reports are generally regenerated 5+ times per week.
It's best to use the latest dependencies.
No response
No response
com.jcraft:jsch is effectively dead (last release from november 2018), but there is an actively maintained fork: https://github.com/mwiede/jsch.
Please consider switching to this fork.
As jcraft:jsch is not maintained any more, it will not receive any new encryption ciphers and will continue to support outdated potentially insecure ciphers.
No response
I stumbled upon this whole situation when I wanted to connect to a git server using a ssh url and it did not work because I used a newer open ssh version to generate my private key.
The new fork does not support this new format as well, but there is at least an issue for it: mwiede/jsch#31
6.6.0 or later
Linux/Unix, MacOS, Windows
When using the SnapshottingRefDirectory
, if a thread has read
packed-refs, then another actor updates packed-refs, the original
thread may create an update that is based on the old cached/snapshotted
packed-refs content. That update could effectively perform a forced
update unintentionally because it is unaware of the new content. This
seems particularly likely to happen in a scenario where a loose ref was
just packed. Our thread would otherwise see the non-snapshotted loose
ref value, but instead relies on its outdated packed-refs snapshot.
The problem is potentially related to the Gerrit Code Review Issue 309098227
where Gerrit multi-site plugin detected an in-memory split-brain where
two threads were trying to update the same ref, with one of the thread
having a stale cached data, which is compatible with the underlying
JGit issue.
In the case of the Gerrit Code Review Issue 309098227,
disabling the use of SnapshottingRefDirectory
solved the problem.
The two threads trying to update the same ref did not have the same view of the underlying ref-db at the time of the ref-update execution.
When two threads are reading concurrently a changing ref-db and starting to update a ref, they should have the same view of the ref-db which corresponds to the latest update performed on disk, regardless of the previously cached value.
No response
No response
6.9.0.202403050737-r
Linux/Unix
Issue #25 changes to try a file path specified in IdentityFile then try with an file extension ".pub".
When user use traditional configuration that IdentityFile path is secret key on file system, JGit and apache MINA sshd library raise an exception and show a stack trace.
A problem is only raised when user also configure IdentiesOnly = yes
.
Here is gerrit entry of the change
https://eclipse.gerrithub.io/c/eclipse-jgit/jgit/+/1177073/6/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd/JGitPublicKeyAuthentication.java
In previous code,
Path p = Paths.get(s + ".pub"); //$NON-NLS-1$
if (Files.isRegularFile(p, LinkOption.NOFOLLOW_LINKS)) {
return AuthorizedKeyEntry.readAuthorizedKeys(p).get(0).resolvePublicKey(null, PublicKeyEntryResolver.IGNORING);
}
It just adding ".pub" and check it, then no exception was observed.
Record stack trace in log file.
Run without exception or don't show a stack trace.
I think we can check existence of public key before try a file path of IdentityFile
specified.
Approach 1. Check existence of file path
Path p = Paths.get(s + ".pub"); //$NON-NLS-1$
and if exists, try it first.
Approach 2. Check specified path endsWith ".pub"
There is not necessary to put a file name rule in a new approach that file system hold only a public key and secret key is in HSM, approach 2 is not stable for future. Old style always has "foo.pub" and "foo" key pair, so approach 1 is better.
Cannot read public key from file /home/miurahr/.ssh/id_ed25519
java.io.StreamCorruptedException: Failed (IllegalArgumentException) to parse key entry=-----BEGIN OPENSSH PRIVATE KEY-----: Bad format (no key data delimiter): KEY-----
at org.apache.sshd.common.config.keys.AuthorizedKeyEntry.readAuthorizedKeys(AuthorizedKeyEntry.java:247)
at org.apache.sshd.common.config.keys.AuthorizedKeyEntry.readAuthorizedKeys(AuthorizedKeyEntry.java:226)
at org.apache.sshd.common.config.keys.AuthorizedKeyEntry.readAuthorizedKeys(AuthorizedKeyEntry.java:211)
at org.apache.sshd.common.config.keys.AuthorizedKeyEntry.readAuthorizedKeys(AuthorizedKeyEntry.java:195)
at org.apache.sshd.common.config.keys.KeyUtils.loadPublicKey(KeyUtils.java:342)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication$KeyIterator.readPublicKey(JGitPublicKeyAuthentication.java:353)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication$KeyIterator.lambda$0(JGitPublicKeyAuthentication.java:330)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication$KeyIterator.getExplicitKeys(JGitPublicKeyAuthentication.java:337)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication$KeyIterator.identitiesOnly(JGitPublicKeyAuthentication.java:434)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication$KeyIterator.initializeAgentIdentities(JGitPublicKeyAuthentication.java:383)
at org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator.<init>(UserAuthPublicKeyIterator.java:59)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication$KeyIterator.<init>(JGitPublicKeyAuthentication.java:320)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication.createPublicKeyIterator(JGitPublicKeyAuthentication.java:137)
at org.apache.sshd.client.auth.pubkey.UserAuthPublicKey.init(UserAuthPublicKey.java:109)
at org.eclipse.jgit.internal.transport.sshd.JGitPublicKeyAuthentication.init(JGitPublicKeyAuthentication.java:123)
at org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:410)
at org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:331)
at org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:267)
at org.apache.sshd.common.session.helpers.CurrentService.process(CurrentService.java:109)
at org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:624)
at org.apache.sshd.common.session.helpers.AbstractSession.lambda$handleMessage$0(AbstractSession.java:545)
at org.apache.sshd.common.util.threads.ThreadUtils.runAsInternal(ThreadUtils.java:68)
at org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:544)
at org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1688)
at org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:505)
at org.eclipse.jgit.internal.transport.sshd.JGitClientSession.messageReceived(JGitClientSession.java:208)
at org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
at org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:409)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:382)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:377)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
at java.base/sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:129)
at java.base/sun.nio.ch.Invoker$2.run(Invoker.java:221)
at java.base/sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:113)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
No response
When trying to access a repository via http, the error message should be something like: "You cannot access repositories via http." instead of "Authentication is required but no CredentialsProvider has been registered."
There are probably more cases than http/https which are covered by this error.
It helps people finding bugs in their software and/or server configuration.
No response
I was using BlueJ and my own git server which I misconfigured so that it only used http instead of https. When I tried to checkout a repository from my server I only got the error message mentioned above. It would have saved me a lot of time finding my mistake if the error message had been referring to what the actual problem was.
6.8.0
Linux/Unix
I use the public RevCommit parseCommit(final AnyObjectId id)
method to get the commit and its content。Over time, my application memory will gradually increase until oom。
After I dumped the memory, I found that the top1 object is PackIndexV2。
I noticed that there is an open operation in the implementation of the parseCommit method, and I suspect that it opened the file without releasing it, causing a memory leak.
So, I logged into the server and used the lsof command to view the pack file opened by the java process.
Moreover, with the end of the stress testing process, the number of open files has not decreased.
After the parseCommit method call ends, the pack file descriptor is not released,
After the parseCommit method is called, the pack file descriptor is released normally to save memory.
No response
No response
2023-12 (4.30.0)
Windows
Failing to perform signed commit using external gpg. See log in "Relevant log output" section.
Failed to perform signed commit
Expected to succeed.
Command line git performs signed commit using the same external gpg, user name and mail successfully
!ENTRY org.eclipse.egit.ui 4 0 2024-01-10 18:31:17.230
!MESSAGE An internal error occurred
!STACK 0
org.eclipse.jgit.api.errors.JGitInternalException: External program failed ([GNUPG:] KEY_CONSIDERED A1427A7A21F2545AAC19BFB1661C4889FE30F3D1 2
[GNUPG:] BEGIN_SIGNING H8
[GNUPG:] PINENTRY_LAUNCHED 11288 w32 1.2.1 - - - - 0/0 -
[GNUPG:] SIG_CREATED D 1 8 00 1704907867 A1427A7A21F2545AAC19BFB1661C4889FE30F3D1
): C:\Users\some_user\AppData\Local\Programs\gnupg\bin\gpg.exe -bsau <[email protected]> --batch --no-tty --status-fd 2 --output -
at org.eclipse.egit.core.internal.signing.ExternalGpgSigner.signObject(ExternalGpgSigner.java:191)
at org.eclipse.jgit.api.CommitCommand.sign(CommitCommand.java:336)
at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:283)
at org.eclipse.egit.core.op.CommitOperation.commit(CommitOperation.java:259)
at org.eclipse.egit.core.op.CommitOperation$1.run(CommitOperation.java:211)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2453)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2478)
at org.eclipse.egit.core.op.CommitOperation.execute(CommitOperation.java:220)
at org.eclipse.egit.ui.internal.commit.CommitJob.run(CommitJob.java:135)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.io.IOException: External program failed ([GNUPG:] KEY_CONSIDERED A1427A7A21F2545AAC19BFB1661C4889FE30F3D1 2
[GNUPG:] BEGIN_SIGNING H8
[GNUPG:] PINENTRY_LAUNCHED 11288 w32 1.2.1 - - - - 0/0 -
[GNUPG:] SIG_CREATED D 1 8 00 1704907867 A1427A7A21F2545AAC19BFB1661C4889FE30F3D1
): C:\Users\some_user\AppData\Local\Programs\gnupg\bin\gpg.exe -bsau <[email protected]> --batch --no-tty --status-fd 2 --output -
at org.eclipse.egit.core.internal.signing.ExternalGpgSigner.runProcess(ExternalGpgSigner.java:135)
at org.eclipse.egit.core.internal.signing.ExternalGpgSigner.signWithGpg(ExternalGpgSigner.java:297)
at org.eclipse.egit.core.internal.signing.ExternalGpgSigner.signObject(ExternalGpgSigner.java:189)
... 9 more
Caused by: java.io.IOException: External GPG did not return a valid signature; got: -----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoUJ6eiHyVFqsGb+xZhxIif4w89EFAmWe1FsACgkQZhxIif4w
89H/xA/8Dbq4pr+wWSMVzcsHwY+gii1FDgbg5zHut6WX+hK8d11mrJTlPbqbyUPq
QFouwB9y3wtIluroF6Ics89wNAlRCBGqGLuHJCpjVHGhyMoyhp5l7X8gF7TORf+a
X/MH3h0pAyKzprRD7sZ3A9RmPL9MBX25KwieuTBbZdhBvWRC2j5dj3RsCBSwn4vn
ZbSB0JawNWSX6qsttH2+8FSgWkZFred2juIUkg0NmJCPF3Lg8GBTiTo366X27/TN
1+hjGl6yUl5pwXKpl2Z4A0fcEbu2A6osmLI64hB09reD7JdlHAtsLUty7Y9mTRyB
qnEsmw5/p7nogFsrAvAmLapD/fm9K6hiu3rzGOpywvFPv45EJzL2HQgzYKyU70fr
ODMVZJET0HKx25LO20rURmuZR+PcSJUE7d/9mjYbpaF3k+5it5kzfRQF2vcV0mGA
dWpnbYFRA8HcvOn6nZIKzNth1roP8lluFvT2AXtLdvLJ27SfUG6JCjgcBe1H5dDY
q9xARe1S78x+uwSrZzTjplit+LHcP6odHqybMJdSL9RiBq4iaYkyf7m8cydKE5Nl
ls9xBBc0ZcNG5m53UtzTU2CVsMzW36VOZUsIUJ5Q1hWhlt5jfBBc9wleXCRCvD1q
FOD5Nul9mMWgCqsouO3nVb0Xa5j64caOiTFD2FL0qoT5TrzMqBg=
=hrDq
-----END PGP SIGNATURE-----
at org.eclipse.egit.core.internal.signing.ExternalGpgSigner.lambda$1(ExternalGpgSigner.java:326)
at org.eclipse.egit.core.internal.signing.ExternalGpgSigner.runProcess(ExternalGpgSigner.java:110)
... 11 more
No response
Will there be fix of https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4759 for the 5.x version? I see from maven central there is no fix https://mvnrepository.com/artifact/org.eclipse.jgit/org.eclipse.jgit. However our project staying with java8 and can not use the 6.x version
I found this thread https://www.eclipse.org/forums/index.php/m/1862132/?srch=CVE-2023-4759#msg_1862132 and according to that, the new 5.13.3 should have the cve fixed, but from the maven-central, it still shows that version has the cve. I also encountered same error when I build my project, I think the authority at https://nvd.nist.gov/vuln/detail/CVE-2023-4759 need to update that this 5.13.3 version is also a fixed version.
https://nvd.nist.gov/vuln/detail/CVE-2023-4759
Can't find a CVE free version for 5.x(java8)
No response
No response
6.9.0
Windows
If I rename somefile
to anotherfile
, commit, then merge from a branch where I have a change to somefile
still with the old name, what I get is a conflict saying that somefile
has been deleted locally.
How to reproduce:
master
create someFile.txt
and commitmyBranch
someFile.txt
master
someFile.txt
to anotherFile.txt
either within Eclipse or from shell with git mv
myBranch
using Eclipsedeleted by us: someFile.txt
git merge myBranch
someFile.txt
have been merged into anotherFile.txt
I expect Eclipse to behave like the external git command does, i.e. merge the changes to the old-named file into the renamed file.
No response
No response
Currently, JGit uses javax.* making it incompatible with newer jakarta.*.
In order to allow other web applications that use JGit the ability to use newer jakarata libs, JGit needs to move away from javax to jakarta.
No response
No response
https://github.com/eclipse-jgit/jgit/security/policy states:
"The community is also encouraged to report vulnerabilities using the Eclipse Foundation's Bugzilla instance. Note that you will require an Eclipse Foundation account to create an issue report, but by doing so you will be able to participate directly in the resolution of the issue.
Issue reports related to vulnerabilities must be marked as "committers-only", either automatically by clicking the provided link, by the reporter, or by a committer during the triage process. Note that issues marked "committers-only" are visible to all Eclipse committers. By default, a "committers-only" issue is also accessible to the reporter and individuals explicitly indicated in the "cc" list.
What is the github issues equivalent that we should be following?
Instructions refer to the previous (bugzilla) bug tracker.
Instructions refer to the current bug tracker.
latest
Linux/Unix, MacOS, Windows
at the end of each platform build an error is logged
exception
no exception, load the text while classloader available or inline string "Cleanup during JVM shutdown failed"
Error: Exception in thread "Thread-3" java.lang.NoClassDefFoundError: org/eclipse/jgit/internal/JGitText
at org.eclipse.jgit.internal.util.ShutdownHook.cleanup(ShutdownHook.java:85)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.lang.ClassNotFoundException: org.eclipse.jgit.internal.JGitText
... 2 more
Error: The process '/Users/runner/hostedtoolcache/maven/3.9.6/x64/bin/mvn' failed with exit code 1
6.6.0
Windows
We try merge the git workspace. If it has conflict binary files, it makes 0 byte file. The same case when we do it using git command, the binary file has maintain the content as local version and marked the file as conflict. We expect the same behavior in JGit API also.
Binary conflicted files(example jpeg file conflict) are empty after merge with JGit API. This makes issue, user does not know the actual content of the file and they cannot open the file in corresponding tools.
The same above case, if I perform the merge using git command, the file content remains as local version content. It marked the file as conflict. Hence user can open the file and see the content and resolve the conflict manually.
We expect the same git command behavior in JGit merge API.
No response
No response
Gradle with the configuration cache enabled, needs to not fork processes. Obviously git is very popular, and integrated with versioning. Unfortunately it seems that jgit, in some cases, and possibly unnecessarily, forks git itself and makes it incompatible with the configuration cache.
2 problems were found storing the configuration cache.
- Plugin 'com.xenoterracide.gradle.sem-ver': external process started '/usr/bin/git --version'
See https://docs.gradle.org/8.6/userguide/configuration_cache.html#config_cache:requirements:external_processes
- Plugin 'com.xenoterracide.gradle.sem-ver': external process started '/usr/bin/git config --system --show-origin --list -z'
See https://docs.gradle.org/8.6/userguide/configuration_cache.html#config_cache:requirements:external_processes
I'm currently not certain if it deals with both forks, but perhaps the environment variable Constants.GIT_CONFIG_NOSYSTEM_KEY could also be set programatically on the builder.
There's this, but I don't know if it's sufficient https://stackoverflow.com/a/59110721/206466
I also believe there may be ways to workaround it with gradle.
I might be willing to take a stab at this, with feedback. Here's what spotless is doing as a workaround
Update minimum Java version to 17
On the jgit-dev list we agreed to update to Java 17
6.8.0.202311291450-r
Linux/Unix
Signing a commit fails when it is enabled in .gitconfig
Doing :
git.commit().setMessage(message).setSigningKey(gpgID).call()
When :
cat ~/.gitconfig
[commit]
gpgsign = true
leads to :
org.eclipse.jgit.api.errors.ServiceUnavailableException: Signing service is not available
at org.eclipse.jgit.api.CommitCommand.sign(CommitCommand.java:328)
at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:283)
see https://hub.spigotmc.org/jira/si/jira.issueviews:issue-html/BUILDTOOLS-536/BUILDTOOLS-536.html
Problem is that it is not really easy to sign git commits with Bouncy Castle at least IDK how.
jgit should either succeed with the defailt GpgSigner
or there should be easy alternative with BouncyCastle
org.eclipse.jgit.api.errors.ServiceUnavailableException: Signing service is not available
at org.eclipse.jgit.api.CommitCommand.sign(CommitCommand.java:328)
at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:283)
### Other information
_No response_
6.8.0.202311291450-r
Linux/Unix, MacOS
The issue is caused when doing a git pull that will lead to a merge conflict with the README.md file in my repository(which is part of the initial repository commit if that is relevant). The merge strategy is set to "recursive" - the default one and the pull is done with rebase.
Pull code:
PullResult result = git.pull()
.setRemoteBranchName("master")
.setTransportConfigCallback(createTransportConfigCallback())
.setRebase(true).call();
Stacktrace:
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at org.eclipse.jgit.revwalk.RevCommit.getParent(RevCommit.java:354) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar:6.8.0.202311291450-r]
at org.eclipse.jgit.api.RebaseCommand.stop(RebaseCommand.java:1070) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar:6.8.0.202311291450-r]
at org.eclipse.jgit.api.RebaseCommand.cherryPickCommitFlattening(RebaseCommand.java:568) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar:6.8.0.202311291450-r]
at org.eclipse.jgit.api.RebaseCommand.cherryPickCommit(RebaseCommand.java:532) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar:6.8.0.202311291450-r]
at org.eclipse.jgit.api.RebaseCommand.processStep(RebaseCommand.java:443) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar:6.8.0.202311291450-r]
at org.eclipse.jgit.api.RebaseCommand.call(RebaseCommand.java:356) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar:6.8.0.202311291450-r]
at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:366) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar:6.8.0.202311291450-r]
ArrayIndexOutOfBoundsException error
Possible merge conflict. This is the output when doing the pull from the terminal on the same repository:
➜ local9b5e52ab-fd06-44e4-b0d3-f5afe3f6a2da git:(main) git pull origin master --rebase
warning: no common commits
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), 245 bytes | 35.00 KiB/s, done.
From https://gitlab-it.sof-mbu.eng.vmware.com/vrouitests/testcontent-push-e2e_git_ckoi_1702975571005
* branch master -> FETCH_HEAD
* [new branch] master -> origin/master
Auto-merging README.md
CONFLICT (add/add): Merge conflict in README.md
error: could not apply 700aedf... Initial commit
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 700aedf... Initial commit
No response
No response
JGit should support X.509 signed commits
Companies have official X.509 certificates and they should be able to leverage existing certified identities
JGit could leverage an external process like smimesign
by spawning a process. However, that would have a detriment effect on the overall system load and latency.
C-Git supports signed X.509 commits, therefore JGit servers (e.g. Gerrit) will have to deal with those signatures anyway.
5.13
MacOS
When clone a remote repository that advertised a large number of refs (e.g. in the order of millions) the JGit client spend a lot of time marking the received refs as locally advertised.
See the full stack-trace below:
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
- locked <0x00000007a69a1728> (a java.io.FileNotFoundException)
at java.lang.Throwable.<init>(Throwable.java:266)
at java.lang.Exception.<init>(Exception.java:66)
at java.io.IOException.<init>(IOException.java:58)
at java.io.FileNotFoundException.<init>(FileNotFoundException.java:77)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at org.eclipse.jgit.internal.storage.file.LooseObjects.getObjectLoader(LooseObjects.java:186)
at org.eclipse.jgit.internal.storage.file.LooseObjects.open(LooseObjects.java:149)
at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openLooseObject(ObjectDirectory.java:396)
at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openLooseFromSelfOrAlternate(ObjectDirectory.java:373)
at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObjectWithoutRestoring(ObjectDirectory.java:349)
at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObject(ObjectDirectory.java:330)
at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:132)
at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:212)
at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:1075)
at org.eclipse.jgit.transport.BasePackFetchConnection.markAdvertised(BasePackFetchConnection.java:987)
at org.eclipse.jgit.transport.BasePackFetchConnection.markRefsAdvertised(BasePackFetchConnection.java:979)
at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:363)
at org.eclipse.jgit.transport.TransportHttp$SmartHttpFetchConnection.doFetch(TransportHttp.java:1550)
at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:302)
at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:293)
at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:274)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:171)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:94)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1309)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:213)
at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:311)
at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:182)
Clone operation is slow
Speed improvement in clone operation
No response
No response
6.8.0.202311291450-r
MacOS
If JGit is configured to use a custom JschConfigSessionFactory
to connect to a locally running ssh-agent
instance via proxy like this:
val factory = object : JschConfigSessionFactory() {
@Throws(JSchException::class)
override fun createDefaultJSch(fs: FS): JSch {
val jsch: JSch = super.createDefaultJSch(fs)
if (SSHAgentConnector.isConnectorAvailable()) {
val factory = ConnectorFactory.getDefault()
val identityRepository = RemoteIdentityRepository(factory.createConnector())
jsch.identityRepository = identityRepository
}
return jsch
}
}
SshSessionFactory.setInstance(factory)
then this RemoteIdentityRepository
will not be used if the user who is running a program with JGit has a local .ssh/config
file that contains one or more references to IdentityFile
s:
IdentityFile ~/.ssh/id_first
IdentityFile ~/.ssh/id_second
The reason for that misbehavior is the following code in org.eclipse.jgit.transport.ssh.jsch.JschConfigSessionFactory
with inline comments what's going on:
protected JSch getJSch(OpenSshConfig.Host hc, FS fs) throws JSchException {
if (defaultJSch == null) {
defaultJSch = createDefaultJSch(fs);
if (defaultJSch.getConfigRepository() == null) {
defaultJSch.setConfigRepository(
new JschBugFixingConfigRepository(config));
}
for (Object name : defaultJSch.getIdentityNames())
byIdentityFile.put((String) name, defaultJSch);
// ^^^ the identities coming from the agent are identified by their name (comment), e.g. "my-first-identity"
}
final File identityFile = hc.getIdentityFile();
// ^^^ here the first identity file from .ssh/config is returned, i.e. /absolute/path/to/.ssh/id_first
if (identityFile == null)
return defaultJSch;
// ^^^ no identity file, no problem, our JSch instance with the remote identity repository is used
final String identityKey = identityFile.getAbsolutePath();
JSch jsch = byIdentityFile.get(identityKey);
// ^^^ now that can never succeed, because the comment of the identity is of course unequal to the path of it's file
if (jsch == null) {
jsch = new JSch();
configureJSch(jsch);
if (jsch.getConfigRepository() == null) {
jsch.setConfigRepository(defaultJSch.getConfigRepository());
}
jsch.setHostKeyRepository(defaultJSch.getHostKeyRepository());
jsch.addIdentity(identityKey);
byIdentityFile.put(identityKey, jsch);
}
return jsch;
}
The overridden JSch instance is thrown away.
The overriden JSch instance should take precedence.
No response
No response
When using the 1Password SSH Agent (https://developer.1password.com/docs/ssh/agent/) it will by default propose all private keys found. As that often conflicts with the max authentication tries on servers (https://developer.1password.com/docs/ssh/agent/advanced#ssh-server-six-key-limit) or is even not supported at all (https://learn.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate?view=azure-devops#q-i-have-multiple-ssh-keys-how-do-i-use-the-correct-ssh-key-for-azure-devops) there is a special mechanism devised outlined at https://developer.1password.com/docs/ssh/agent/advanced#match-key-with-host:
IdentityFile
(instead of the private one)(Usually all public keys in no specific order are used against the server which will request a signature if it recognizes the given public key)
The same approach seems to be used by other password managers like KeePass XC (https://keepassxc.org/docs/#faq-ssh-agent-openssh). It is supported in IntelliJ already fine: https://youtrack.jetbrains.com/issue/IDEA-249562/SSH-wont-connect-with-public-key-in-IdentityFile
Exporting private keys to the filesystem is less secure than directly reusing it from a vault of a password manager but obviously works as workaround.
No response
is this suppose to be defined outside the loop? otherwise the value of 'endOfChunk' is always zero and the value 'mergeChunk.end' assigned to 'endOfChunk' defined in org.eclipse.jgit.api.MergeResult.addConflict' is never used
5.13
Windows
I am performing https git clone operation on Azure repository and the request is failing with kerberos auth failure. I am not sure if I am using kerberos internally in my application but this happens only with Azure repository clone action. I tried setting up using "PAT" also but that also didn't help (Attached stacktrace as well)
Error -
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:454)
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
org.eclipse.jgit.transport.HttpAuthMethod$Negotiate.configureRequest(HttpAuthMethod.java:541)
org.eclipse.jgit.transport.TransportHttp.httpOpen(TransportHttp.java:561)
org.eclipse.jgit.transport.TransportHttp.httpOpen(TransportHttp.java:523)
org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:462)
org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:296)
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
com.xx.git.commands.CloneCommand.fetch(CloneCommand.java:222)
com.xx.git.commands.CloneCommand.call(CloneCommand.java:146)
com.xx.git.GitScmService.clone(GitScmService.java:152)
com.xx.git.GitScmService$$FastClassBySpringCGLIB$$e66ae5b2.invoke()
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:793)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763)
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:89)
com.xx.actions.AutoActionTaskAspect.injectScmChangeInfoBuilderAdvice(AutoActionTaskAspect.java:139)
sun.reflect.GeneratedMethodAccessor397.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:634)
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:624)
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:72)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763)
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763)
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:708)
com.xx.git.GitScmService$$EnhancerBySpringCGLIB$$f03c65a8.clone()
com.xx.git.GitConnectionService.cloneRemoteRepository(GitConnectionService.java:336)
com.xx.git.GitConnectionService.cloneAction(GitConnectionService.java:426)
com.xx.git.GitConnectionService.access$200(GitConnectionService.java:84)
com.xx.git.GitConnectionService$1.construct(GitConnectionService.java:224)
com.xx.git.GitConnectionService$1.construct(GitConnectionService.java:211)
com.xx.git.GitConnectionService$2.construct(GitConnectionService.java:234)
com.xx.git.GitConnectionService$2.construct(GitConnectionService.java:231)
com.iconclude.dharma.app.dialogue.TaskProgressDialog$1.doInBackground(TaskProgressDialog.java:373)
javax.swing.SwingWorker$1.call(SwingWorker.java:295)
java.util.concurrent.FutureTask.run(FutureTask.java:266)
javax.swing.SwingWorker.run(SwingWorker.java:334)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:750)
Error -
com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:925)
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:766)
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:618)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
javax.security.auth.login.LoginContext.login(LoginContext.java:587)
sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
sun.security.jgss.krb5.Krb5Util.getInitialTicket(Krb5Util.java:175)
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:377)
sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:373)
java.security.AccessController.doPrivileged(Native Method)
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:372)
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:160)
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:189)
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
org.eclipse.jgit.transport.HttpAuthMethod$Negotiate.configureRequest(HttpAuthMethod.java:541)
org.eclipse.jgit.transport.TransportHttp.httpOpen(TransportHttp.java:561)
org.eclipse.jgit.transport.TransportHttp.httpOpen(TransportHttp.java:523)
org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:462)
org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:296)
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
com.xx.git.commands.CloneCommand.fetch(CloneCommand.java:222)
com.xx.git.commands.CloneCommand.call(CloneCommand.java:146)
com.xx.git.GitScmService.clone(GitScmService.java:152)
com.xx.git.GitScmService$$FastClassBySpringCGLIB$$e66ae5b2.invoke()
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:793)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763)
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:89)
com.xx.actions.AutoActionTaskAspect.injectScmChangeInfoBuilderAdvice(AutoActionTaskAspect.java:139)
sun.reflect.GeneratedMethodAccessor242.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:634)
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:624)
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:72)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763)
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763)
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:708)
com.xx.git.GitScmService$$EnhancerBySpringCGLIB$$603f33c2.clone()
com.xx.git.GitConnectionService.cloneRemoteRepository(GitConnectionService.java:336)
com.xx.git.GitConnectionService.cloneAction(GitConnectionService.java:426)
com.xx.git.GitConnectionService.access$200(GitConnectionService.java:84)
com.xx.git.GitConnectionService$1.construct(GitConnectionService.java:224)
com.xx.git.GitConnectionService$1.construct(GitConnectionService.java:211)
com.xx.git.GitConnectionService$2.construct(GitConnectionService.java:234)
com.xx.git.GitConnectionService$2.construct(GitConnectionService.java:231)
com.iconclude.dharma.app.dialogue.TaskProgressDialog$1.doInBackground(TaskProgressDialog.java:373)
javax.swing.SwingWorker$1.call(SwingWorker.java:295)
java.util.concurrent.FutureTask.run(FutureTask.java:266)
javax.swing.SwingWorker.run(SwingWorker.java:334)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:750)
Followed some remedies :-
Try this steps : - https://groups.google.com/g/gatling/c/4L_OofnOQy0?pli=1
Control Panel > Credential Manager Check if creds stored in generic password is accurate or not for azure network address.
add the IP address of the server in its host file. You must also recycle the application server to load the new host file.
Run "Klist" command that comes with java Check for server by name kerberos (like Server: krbtgt...)
https://support.tibco.com/s/article/Spotfire-Server-KERBEROS-ERROR-No-valid-credentials-provided-Mechanism-level-No-valid-credentials-provided-Mechanism-level-Connection-timed-out-connect
Versions :- I am using jdk 8 version. Our dekstop application uses Git 2.39.2.windows.1 version to perform clone. org.eclipse.jgit.ssh.jsch-5.13.1.202206130422-r.jar
org.eclipse.jgit.ui-5.13.1.202206130422-r.jar
org.eclipse.jgit-5.13.1.202206130422-r.jar
Authentication should passed as expected. I tested seperately using git cli (same version) and it works fine.
Issue should get resolved
No response
No response
6.8.0.202311291450-r
Linux/Unix
When .gnupg/private-keys-v1.d
contains ed25519 key, the class BouncyCastleGpgKeyLocator fails, error occurs here:
https://github.com/eclipse-jgit/jgit/blob/master/org.eclipse.jgit.gpg.bc/src/org/eclipse/jgit/gpg/bc/internal/keys/SecretKeys.java#L134
Cause is most probably
bcgit/bc-java#1590
Currently new PGPException("no q value found")
is hit and operation fails.
To have ed25519 key loaded up.
Caused by: org.bouncycastle.openpgp.PGPException: no q value found
at org.eclipse.jgit.gpg.bc.internal.keys.SExprParser.parseSecretKey (SExprParser.java:134)
at org.eclipse.jgit.gpg.bc.internal.keys.SecretKeys.readSecretKey (SecretKeys.java:152)
No response
See https://git-scm.com/docs/git-restore
Reference git implementation supports that.
No response
No response
6.9.0
Windows
Trying to push a commit to GitHub that contains a new Large File Storage (LFS) object fails with a message that says that the referenced LFS object is missing
But the object exists in the local LFS cache and I also debugged the code and verified that LfsPrePushHook.uploadFile()
is called and succeeds for the file mentioned in the error message.
Switching between the Apache Http and the JDK's http client makes no difference.
Pushing failes with the described message.
Push succeeds and the LFS objects are properly pushed along with the pointer file.
Repository [email protected]:HannesWell/my.git.lfs.tests.git
pre-receive hook declined
error: GH008: Your push referenced at least 1 unknown Git LFS object:
cdb81c2552ec215adc17feb7665f9b7532beec6735816a040798207dc0e71994
Try to push them with 'git lfs push --all'.
The repositories .git/config
:
[core]
repositoryformatversion = 0
filemode = false
logallrefupdates = true
[remote "origin"]
url = [email protected]:HannesWell/my.git.lfs.tests.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
merge = refs/heads/main
rebase = false
remote = origin
[lfs]
repositoryformatversion = 0
My global ~/.gitconfig
[http]
sslVerify = false
[push]
default = simple
[core]
autocrlf = true
safecrlf = true
[filter "lfs"]
useJGitBuiltin = true
required = true
smudge = git-lfs smudge -- %f
process = git-lfs filter-process
clean = git-lfs clean -- %f
All releases from v4.10.* onwards
Linux/Unix
Bare repos can be at time transferred at the filesystem level (with the target location in read-only until the transfer is complete) across Gerrit servers.
I am running on defaults for JGit and Gerrit.
Example:
I do not see anything wrong with the above approach, as long as Server-2 is read-only until the transfer is complete.
At point 5. the sshd_log shows that the bitmap is not used. After a full restart of Gerrit, the action 5. reports that the bitmap is used in the sshd_log.
At point 5. the sshd_log shows that the bitmap is used
See the log of the sshd_log execution on a Gerrit v3.5.6 (JGit 6.6.0 @74fa245b3c3ccf13afcbec7911c7c8459e48527d)
At point 2. clone without bitmap:
[2024-01-12T10:32:32.491Z] 33cc307a [SSH git-upload-pack /repo1 (admin)] admin a/1000000 git-upload-pack./repo1 5ms 55ms '0ms 27ms 0ms 8ms 0ms 4ms 39ms -1 141 440 37967' 0 - 47ms 40ms 1493344
At point 5. clone with bitmap:
[2024-01-12T10:39:22.108Z] 53bd24d6 [SSH git-upload-pack /repo1 (admin)] admin a/1000000 git-upload-pack./repo1 6ms 54ms '0ms 28ms 0ms 7ms 0ms 4ms 39ms -1 141 440 37967' 0 - 42ms 30ms 1474304
After a Gerrit restart, at point 5. clone with bitmap:
[2024-01-12T10:40:37.388Z] a5799f52 [SSH git-upload-pack /repo1 (admin)] admin a/1000000 git-upload-pack./repo1 4ms 60ms '0ms 39ms 0ms 1ms 0ms 5ms 45ms 0 141 440 37971' 0 - 54ms 40ms 895768
See Change 1174396
Upstream will release a new release 2.12.0 soon. Update the minimum required version in JGit to 2.12.0.
That upstream release includes the fix for CVE-2023-48795 ("strict KEX" protocol extension mitigating the "Terrapin attack").
By bumping the dependency in JGit o 2.12.0, JGit will profit from this CVE fix.
No response
No response
At bndtools we got bndtools/bnd#5908
Analyzing how it is possible that JGit cannot find the javax.net.sll.SSLContext
class, I looked at the bundle org.eclipse.jgit.http.apache where the error occurred.
[MANIFEST]
Automatic-Module-Name org.eclipse.jgit.http.apache
Build-Jdk-Spec 11
Bundle-ActivationPolicy lazy
Bundle-Localization plugin
Bundle-ManifestVersion 2
Bundle-Name %Bundle-Name
Bundle-RequiredExecutionEnvironment JavaSE-11
Bundle-SymbolicName org.eclipse.jgit.http.apache
Bundle-Vendor %Bundle-Vendor
Bundle-Version 6.3.0.202209071007-r
Created-By Maven Jar Plugin 3.2.0
Export-Package org.eclipse.jgit.transport.http.apache.internal;x-internal:=true
org.eclipse.jgit.transport.http.apache;version="6.3.0"; uses:="org.apache.http.client, org.eclipse.jgit.transport.http, org.apache.http.entity, org.apache.http.client.methods, javax.net.ssl, org.eclipse.jgit.util, org.apache.http"
Implementation-Title JGit org.eclipse.jgit.http.apache
Implementation-Vendor Eclipse.org - JGit
Implementation-Vendor-Id org.eclipse.jgit
Implementation-Vendor-URL https://www.eclipse.org/jgit/
Implementation-Version 6.3.0.202209071007-r
Import-Package org.apache.http.client.config;version="[4.4.0,5.0.0)"
org.apache.http.client.methods;version="[4.4.0,5.0.0)"
org.apache.http.client.params;version="[4.4.0,5.0.0)"
org.apache.http.client;version="[4.4.0,5.0.0)"
org.apache.http.config;version="[4.3.0,5.0.0)"
org.apache.http.conn.params;version="[4.4.0,5.0.0)"
org.apache.http.conn.scheme;version="[4.4.0,5.0.0)"
org.apache.http.conn.socket;version="[4.4.0,5.0.0)"
org.apache.http.conn.ssl;version="[4.4.0,5.0.0)"
org.apache.http.conn.util;version="[4.4.0,5.0.0)"
org.apache.http.conn;version="[4.4.0,5.0.0)"
org.apache.http.entity;version="[4.3.0,5.0.0)"
org.apache.http.impl.client;version="[4.4.0,5.0.0)"
org.apache.http.impl.conn;version="[4.4.0,5.0.0)"
org.apache.http.params;version="[4.3.0,5.0.0)"
org.apache.http.ssl;version="[4.3.0,5.0.0)"
org.apache.http;version="[4.3.0,5.0.0)"
org.eclipse.jgit.annotations;version="[6.3.0,6.4.0)"
org.eclipse.jgit.nls;version="[6.3.0,6.4.0)"
org.eclipse.jgit.transport.http;version="[6.3.0,6.4.0)"
org.eclipse.jgit.util;version="[6.3.0,6.4.0)"
Manifest-Version 1.0
The manifest is clearly not importing this package. Looking at the analysis of the jar:
[USES]
org.eclipse.jgit.transport.http.apache javax.net.ssl
org.apache.http
org.apache.http.client
org.apache.http.client.config
org.apache.http.client.methods
org.apache.http.config
org.apache.http.conn
org.apache.http.conn.socket
org.apache.http.conn.ssl
org.apache.http.entity
org.apache.http.impl.client
org.apache.http.impl.conn
org.apache.http.ssl
org.eclipse.jgit.lib
org.eclipse.jgit.transport.http
org.eclipse.jgit.transport.http.apache.internal
org.eclipse.jgit.util
org.eclipse.jgit.transport.http.apache.internal org.eclipse.jgit.nls
[USEDBY]
javax.net.ssl org.eclipse.jgit.transport.http.apache
So the code clearly references this package.
I am not sure how you generate the manifest here in this project, but looking at manifest I see:
Import-Package: org.apache.http;version="[4.3.0,5.0.0)",
org.apache.http.client;version="[4.4.0,5.0.0)",
org.apache.http.client.config;version="[4.4.0,5.0.0)",
org.apache.http.client.methods;version="[4.4.0,5.0.0)",
org.apache.http.client.params;version="[4.4.0,5.0.0)",
org.apache.http.config;version="[4.3.0,5.0.0)",
org.apache.http.conn;version="[4.4.0,5.0.0)",
org.apache.http.conn.params;version="[4.4.0,5.0.0)",
org.apache.http.conn.scheme;version="[4.4.0,5.0.0)",
org.apache.http.conn.socket;version="[4.4.0,5.0.0)",
org.apache.http.conn.ssl;version="[4.4.0,5.0.0)",
org.apache.http.conn.util;version="[4.4.0,5.0.0)",
org.apache.http.entity;version="[4.3.0,5.0.0)",
org.apache.http.impl.client;version="[4.4.0,5.0.0)",
org.apache.http.impl.conn;version="[4.4.0,5.0.0)",
org.apache.http.params;version="[4.3.0,5.0.0)",
org.apache.http.ssl;version="[4.3.0,5.0.0)",
org.eclipse.jgit.annotations;version="[6.8.0,6.9.0)",
org.eclipse.jgit.nls;version="[6.8.0,6.9.0)",
org.eclipse.jgit.transport.http;version="[6.8.0,6.9.0)",
org.eclipse.jgit.util;version="[6.8.0,6.9.0)"
Which clearly does not show javax.net.ssl?
I am really puzzled how this could've worked ever?
6.9.0.202403050737-r
Linux/Unix, MacOS, Windows
As a follow-up to #38, I am bringing a case where jgit's diff3 output differs from git's diff3 output. Consider the following files:
a
b
c
d
a
H
E
c
d
a
F
E
c
d
When merging those with jgit in diff3 mode, I get:
a
<<<<<<< ours
H
||||||| base
=======
F
>>>>>>> theirs
E
c
d
The problem here is that the b
from the base revision is not visible anymore.
Granted, the output can be explained with the interpretation that both sides replaced b
by E
(which is therefore done outside of the conflict), and then the conflict itself is only about determining whether to insert H
or F
before that.
But it defeats the purpose of the diff3 style a little, since the contents of the base revision are obscured.
Using git
's diff3 output, we get:
a
<<<<<<< ours
H
E
||||||| base
b
=======
F
E
>>>>>>> theirs
c
d
Although the conflict hunk is larger, I find that more helpful because the contents of the base revision are clear.
Using git
's zdiff3 output, we get:
a
<<<<<<< ours
H
||||||| base
b
=======
F
>>>>>>> theirs
E
c
d
That's pretty ideal, and would be worth supporting by jgit, but perhaps rather as a separate mode (called, say, zdiff3
)?
No response
See this helpful blog post about the differences between diff3 and zdiff3:
https://ductile.systems/zdiff3/
JGit should support the Java 8 Path
API as follows:
java.io.File
instances would be overloaded to also accept java.nio.file.Path
.File
arguments would be kept, but would use file.toPath()
and then call their Path
counterparts.Path
API.While writing a server application that clones repos, performs commits and pushes them, I encountered problems when trying to delete the repos afterwards: it seems that even after the Git
instance was closed, (some?) files in .git
are locked for some (short?) time.
If JGit supported the Path API, one could solve this problem by instantiating an in-memory Java filesystem like Jimfs that only exists for the duration of the JGit operations (using a try-with-resources block):
try (var fileSystem = Jimfs.newFileSystem(Configuration.unix())) {
Path repoDirectory = fileSystem.getPath("/repo");
try (var git = cloneRepository(repoDirectory)) {
// perform operations like commit or push
}
}
Other situations where this would offer advantages include:
OutOfMemoryErrors
, but the application keeps running. But with a real disks, all it takes is one too-large operation (or too many failed cleanups) - and the entire system comes to a halt!Both workarounds bring their own caveats and complexities.
No response
6.8.0
Linux/Unix
While running the load tests with multiple users create and and updating the GIT repo's, we encounter the following error
Caused by: org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of add command
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:244) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at com.rapidminer.git.jgit.AbstractJGitRepository.add(AbstractJGitRepository.java:267) ~[adapter-2.0.2-20240430.jar!/:2.0.2-20240430]
... 141 common frames omitted
Caused by: org.eclipse.jgit.errors.LockFailedException: Cannot lock /rapidminer-workspace-service/c8007e1a-685a-404f-ac48-9b4837748ae4/465c4b19-53e2-46ae-ab11-6588cd86e173/.git/index. Ensure that no other process has an open file handle on the lock file /rapidminer-workspace-service/c8007e1a-685a-404f-ac48-9b4837748ae4/465c4b19-53e2-46ae-ab11-6588cd86e173/.git/index.lock, then you may delete the lock file and retry.
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:222) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:293) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:259) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.lib.Repository.lockDirCache(Repository.java:1294) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:129) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
... 142 common frames omitted
Though we ensure the locking while performing the WRITE operation to repository, we end up with above errors.
Is there a way(API) to check whether the repository is already locked by another process, and to wait till it completes.
Please let me know your suggestions.
Thanks
Caused by: org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of add command
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:244) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at com.rapidminer.git.jgit.AbstractJGitRepository.add(AbstractJGitRepository.java:267) ~[adapter-2.0.2-20240430.jar!/:2.0.2-20240430]
... 141 common frames omitted
Caused by: org.eclipse.jgit.errors.LockFailedException: Cannot lock /rapidminer-workspace-service/c8007e1a-685a-404f-ac48-9b4837748ae4/465c4b19-53e2-46ae-ab11-6588cd86e173/.git/index. Ensure that no other process has an open file handle on the lock file /rapidminer-workspace-service/c8007e1a-685a-404f-ac48-9b4837748ae4/465c4b19-53e2-46ae-ab11-6588cd86e173/.git/index.lock, then you may delete the lock file and retry.
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:222) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:293) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:259) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.lib.Repository.lockDirCache(Repository.java:1294) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:129) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
... 142 common frames omitted
No errors and READ/WRITES should be successful
Caused by: org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of add command
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:244) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at com.rapidminer.git.jgit.AbstractJGitRepository.add(AbstractJGitRepository.java:267) ~[adapter-2.0.2-20240430.jar!/:2.0.2-20240430]
... 141 common frames omitted
Caused by: org.eclipse.jgit.errors.LockFailedException: Cannot lock /rapidminer-workspace-service/c8007e1a-685a-404f-ac48-9b4837748ae4/465c4b19-53e2-46ae-ab11-6588cd86e173/.git/index. Ensure that no other process has an open file handle on the lock file /rapidminer-workspace-service/c8007e1a-685a-404f-ac48-9b4837748ae4/465c4b19-53e2-46ae-ab11-6588cd86e173/.git/index.lock, then you may delete the lock file and retry.
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:222) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:293) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:259) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.lib.Repository.lockDirCache(Repository.java:1294) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:129) ~[org.eclipse.jgit-6.8.0.202311291450-r.jar!/:6.8.0.202311291450-r]
... 142 common frames omitted
No response
default
Windows
https://projects.eclipse.org/projects/technology.jgit/developer "Report a Bug" etc fails
https://projects.eclipse.org/list-of-projects?combine=jgit&field_project_techology_types_tid=All&field_state_value_2=All "Report an issue" fails
xyzzy
xyzzy
xyzzy
xyzzy
6.8.0.202311291450-r
Windows
Add Cygwin in your Windows Path Environment Variable
Launch Eclipse and Configure Eclipse eGit preferences to use External Tool for Git diff or merge
In Git Staging View, double click on a modified file.
We get the following message :
Failed to run external merge tool.
Merge aborted!
JGit: tool execution return code: 127
checkExitCode: true
execError: true
stderr:
C:\Users\xxx\AppData\Local\Temp.{}13599643848199867671{}jgit_tool.sh: line 1: C:UsersxxxAppDataLocalTemp.{}13599643848199867671{_}_jgit_tool.sh: command not found
The external tool should be launched for Git Diff or Merge without error
No response
The JGit bug is located in CommandExecutor.createCommandArray() (of org.eclipse.jgit 6.8.0.202311291450-r) at line 168 :
} else if (fs instanceof FS_Win32) {
...
} else if (fs instanceof FS_Win32_Cygwin) {
...
commandArray[0] = commandFile.getCanonicalPath().replace("
", "/"); //$NON-NLS-1$ //$NON-NLS-2$
} else {
If Cygwin/bin is part of the Windows path, fs is instantiated as FS_Win32_Cygwin which is a sub class of FS_Win32.
Since JGit tests FS_Win32 before FS_Win32_Cygwin, we always end up in the FS_Win32 branch and never in the FS_Win32_Cygwin branch, even if fs is a FS_Win32_Cygwin.
As a result, the .replace("\", "/") is never done.
In CommandExecutor.run() line 78,
ProcessBuilder pb = fs.runInShell(commandArray[0],
The runInShell() call invokes the FS_Win32_Cygwin version which executes "sh.exe -c" instead of "cmd.exe /c" (like in FS_Win32).
However, in the case of "sh.exe -c", the following command should not contain any backslashes (which are interpreted as escaping characters), but slashes, which is not the case because the .replace("\", "/") hasn't been done.
6.7.0.202309050840-r
MacOS
When running the git-commit-id-maven-plugin (which uses jgit under the hood) a warning about unknown commit-graph chunk is reported.
This warning seems to only be reproducible under mac using a
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /Users/khm/tools/maven
Java version: 21.0.1, vendor: Oracle Corporation, runtime: /Users/khm/.sdkman/candidates/java/21.0.1-open
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
The message templates are defined in:
and the error observed comes from:
When running jgit a warning about an unknown commit-graph chunk is reported:
[INFO] --- git-commit-id:7.0.0:revision (default) @ tree ---
[WARNING] unknown commit-graph chunk: 0x47444132
[WARNING] unknown commit-graph chunk: 0x47444132
[WARNING] unknown commit-graph chunk: 0x47444132
[WARNING] unknown commit-graph chunk: 0x47444132
No warning.
No response
To reproduce checkout the branch https://github.com/khmarbaise/maven-it-extension/tree/git-commit-id-maven-plugin-issue-687
and run mvn clean verify
.
Can be reproduced using:
Apache Maven 4.0.0-alpha-10 (89d3c0321dda868c432edf504f1884e6fd706f00)
Maven home: /Users/khm/tools/maven
Java version: 21.0.1, vendor: Oracle Corporation, runtime: /Users/khm/.sdkman/candidates/java/21.0.1-open
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /Users/khm/tools/maven
Java version: 21.0.1, vendor: Oracle Corporation, runtime: /Users/khm/.sdkman/candidates/java/21.0.1-open
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
mvn --version
Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
Maven home: /Users/khm/tools/maven
Java version: 21.0.1, vendor: Oracle Corporation, runtime: /Users/khm/.sdkman/candidates/java/21.0.1-open
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
Can not be reproduced under linux and the same repository/branch/commit.
original bug-report: git-commit-id/git-commit-id-maven-plugin#687
RefDirectory:pack might raise an NPE when deleting loose refs as final part of the RefDirectory.pack():
java.lang.NullPointerException
at org.eclipse.jgit.internal.storage.file.RefDirectory.pack(RefDirectory.java:817)
at org.eclipse.jgit.internal.storage.file.RefDirectory.pack(RefDirectory.java:729)
at org.eclipse.jgit.internal.storage.file.PackedBatchRefUpdate.execute(PackedBatchRefUpdate.java:153)
at org.eclipse.jgit.lib.BatchRefUpdate.execute(BatchRefUpdate.java:589)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:249)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:105)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1462)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1390)
This is happening because the code correctly locks the packed-refs file in RefDirectory:pack.
However, it makes the wrong assumption considering the loose refs set as immutable between during the whole packing process.
The number and values of loose refs on the filesystem can mutate at any time whilst the RefDirectory.pack() is in progress.
Assuming the contrary can lead to an NPE.
6.10.0
Linux/Unix, MacOS, Windows
The MANIFEST.MF contains an Import-Package for org.bouncycastle.asn1.cryptlib
. This package is no longer exported by newer BC versions, and is in fact not used anymore since commit 68a638d (2021-09-29).
MANIFEST.MF contains this package import; the bundle resolution fails with BouncyCastle 1.78. C.f. eclipse-platform/eclipse.platform.releng.aggregator#1968.
MANIFEST.MF does not contain this package import and bundle resolution against BouncyCastle 1.78 works.
No response
No response
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.