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's People
Contributors
Stargazers
Watchers
Forkers
pkriens laeubi xingole openl-tablets iloveeclipse sepatel profhenry hushrush jvalkeal orange-guo jeanneshao ekennedy80 kwin happycode365 niyw matthiasblaesing forifido andrew-tram baipengyan yurkom deenu488 miurahr gitliveapp to-fr olamy robin536180 bannmann mandymeindersma oss-evaluation-repository ahelwer roanh aktasmuhammetjgit's Issues
Repack Command not found
Description
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.
Motivation
It is a core bit of git functionality and would help prevent out of memory issues when working with poorly packed git repositories.
Alternatives considered
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.
Additional context
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.
Conditional Include in gitconfig
Description
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
Motivation
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
Alternatives considered
The only workaround would be repository specific configurations which leads to a lot of config duplication and effort to initially set this correctly
Additional context
No response
jgit wiki pages contain unwanted escaped newline character
Version
Operating System
Windows
Bug description
21 of the jgit wiki pages have this kind of bad newline:
Actual behavior
Expected behavior
Relevant log output
No response
Other information
@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).
Incorrect merge conflict in diff3 style
Version
6.9.0.202403050737-r
Operating System
Linux/Unix, MacOS, Windows
Bug description
The jgit library produces invalid conflicts when using the "diff3" style. Consider the following example:
Ours
a
d
Base
a
b
d
Theirs
a
b
c
d
In other words, ours deletes the b line and theirs keeps it but inserts the c line after it.
Actual behavior
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)
Expected behavior
The merged result should be
a
<<<<<<< OURS
||||||| BASE
b
=======
b
c
>>>>>>> THEIRS
d
Relevant log output
No response
Other information
No response
java.lang.NoClassDefFoundError: org/eclipse/jgit/internal/JGitText
Version
5.13.0 probably (the one used by tycho qualifier computer)
Operating System
Linux/Unix
Bug description
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):
Actual behavior
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
Expected behavior
No error.
Relevant log output
No response
Other information
Some analysis of the problem here: eclipse-pde/eclipse.pde#1020 (comment)
Jetty 10 is at End of Community Support - upgrade to Jetty 12
Version
All
Operating System
Linux/Unix
Bug description
jgit is still using an End of Community Support version of Jetty.
See:
Actual behavior
Not possible to use the only supported version of Jetty at the moment.
Expected behavior
Upgrade to Jetty 12.
Note: if you want to stick with the javax.servlet namespace, then use the ee8 environment on Jetty 12.
Relevant log output
No response
Other information
No response
Support commit signing with SSH key
Description
I would like to be able to sign commits using an SSH key, which is possible since Git 2.34.0.
Motivation
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.
Alternatives considered
I have considered...
- not signing my commits at all
- signing them with GPG instead
Additional context
No response
Add support for blobless clones
Description
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
Motivation
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.
Alternatives considered
The current alternative is to ask users to not use blobless clones, or to stop using JGit and use the native Git CLI.
Additional context
https://community.sonarsource.com/t/missing-blob-jgit-error-with-sonarcloud/109574
https://community.sonarsource.com/t/scan-on-git-blobless-clone-failed/106038
Fetch with protocol V2 fail if wanted ref has been updated during fetch
Version
6.9.0
Operating System
Linux/Unix, MacOS
Bug description
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.
Actual behavior
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
Expected behavior
The fetch or mirror clone works and all objects are being transferred.
Relevant log output
No response
Other information
No response
Unconditional addition of BouncyCastle provider breaks usage of other Providers
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.
java.lang.ClassNotFoundException: org.eclipse.jgit.internal.JGitText
Version
default
Operating System
Linux/Unix
Bug description
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
Actual behavior
see above
Expected behavior
see above
Relevant log output
see aboveOther information
see above
.setTags(true) doesn't work exactly like --tags
Version
6.8.0.202311291450-r
Operating System
Linux/Unix
Bug description
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();
}Actual behavior
git describe #v0.9.2-5-g8ed3c02
git describe --tags #v0.9.3jgit
version: 0.9.2-5-g8ed3c02
Expected behavior
should behave like git describe --tags
Relevant log output
No response
Other information
https://github.com/xenoterracide/gradle-semver/actions/runs/8071119003/job/22050029061
the behavior is the same without this change
Gradle plugin Compatibility ?
Description
Hello,
Is it possible to make a plugin for Gradle ?
Motivation
I would like to use JGit to manage my versions and my Git repository in the file "build.gradle.kts".
Alternatives considered
No response
Additional context
No response
Keep target platform dependencies up-to-date
Description
Description
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.
Minor Updates
Motivation
It's best to use the latest dependencies.
Alternatives considered
No response
Additional context
No response
Use mwiede/jsch fork of jsch
Description
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.
Motivation
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.
Alternatives considered
No response
Additional context
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
Use of SnapshottingRefDirectory can use a stale loose ref upon updates
Version
6.6.0 or later
Operating System
Linux/Unix, MacOS, Windows
Bug description
The Problem
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.
Actual behavior
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.
Expected behavior
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.
Relevant log output
No response
Other information
No response
Degrade: when ssh/config IdentityFile is secret key, raise exception java.io.StreamCorruptedException: Failed (IllegalArgumentException) to parse key entry=-----BEGIN OPENSSH PRIVATE KEY-----: Bad format (no key data delimiter): KEY-----
Version
6.9.0.202403050737-r
Operating System
Linux/Unix
Bug description
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.
Actual behavior
Record stack trace in log file.
Expected behavior
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.
Relevant log output
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)Other information
No response
Add more specific error message when trying to access http repositories
Description
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.
Motivation
It helps people finding bugs in their software and/or server configuration.
Alternatives considered
No response
Additional context
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.
After calling the revwalk.parseCommit method, the file handle is not released, which may cause a memory leak.
Version
6.8.0
Operating System
Linux/Unix
Bug description
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.
Actual behavior
After the parseCommit method call ends, the pack file descriptor is not released，
Expected behavior
After the parseCommit method is called, the pack file descriptor is released normally to save memory.
Relevant log output
No response
Other information
No response
Signed commit failure
Version
2023-12 (4.30.0)
Operating System
Windows
Bug description
Failing to perform signed commit using external gpg. See log in "Relevant log output" section.
Actual behavior
Failed to perform signed commit
Expected behavior
Expected to succeed.
Command line git performs signed commit using the same external gpg, user name and mail successfully
Relevant log output
!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 moreOther information
No response
CVE-2023-4759 fix for 5.x version?
Description
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
Motivation
Can't find a CVE free version for 5.x(java8)
Alternatives considered
No response
Additional context
No response
Merging does not follow renames
Version
6.9.0
Operating System
Windows
Bug description
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.
Actual behavior
How to reproduce:
- on
mastercreatesomeFile.txtand commit - create a new branch
myBranch - on this branch edit and commit
someFile.txt - go back to
master - rename
someFile.txttoanotherFile.txteither within Eclipse or from shell withgit mv - commit
- merge from
myBranchusing Eclipse - --> a merge conflict is reported
- --> git status from the shell shows
deleted by us: someFile.txt - reset hard and merge from shell with
git merge myBranch - --> all is fine and the changes to
someFile.txthave been merged intoanotherFile.txt
Expected behavior
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.
Relevant log output
No response
Other information
No response
JGit Compatability with Jakarta EE10
Description
Currently, JGit uses javax.* making it incompatible with newer jakarta.*.
Motivation
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.
Alternatives considered
No response
Additional context
No response
Security bug reporting instructions refer to Bugzilla
Bug description
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?
Actual behavior
Instructions refer to the previous (bugzilla) bug tracker.
Expected behavior
Instructions refer to the current bug tracker.
ShutdownHook: NoClassDefFoundError
Version
latest
Operating System
Linux/Unix, MacOS, Windows
Bug description
at the end of each platform build an error is logged
Actual behavior
exception
Expected behavior
no exception, load the text while classloader available or inline string "Cleanup during JVM shutdown failed"
Relevant log output
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 1Other information
Binary Conflict file is empty (0 byte file).
Version
6.6.0
Operating System
Windows
Bug description
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.
Actual behavior
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.
Expected behavior
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.
Relevant log output
No response
Other information
No response
No forking process when building a Repository object
Description
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.
Alternatives considered
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.
Additional context
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
Description
Update minimum Java version to 17
Motivation
- Current LTS version of Java is now 21.
- We want to udpate to Jetty 12 (#41) which requires Java 17.
Alternatives considered
- Currently we use Java 11
- We could update right away to Java 21
Additional context
On the jgit-dev list we agreed to update to Java 17
Signing service is not available
Version
6.8.0.202311291450-r
Operating System
Linux/Unix
Bug description
Signing a commit fails when it is enabled in .gitconfig
Actual behavior
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.
Expected behavior
jgit should either succeed with the defailt GpgSigner or there should be easy alternative with BouncyCastle
Relevant log output
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_
ArrayIndexOutOfBoundsException when doing a git pull
Version
6.8.0.202311291450-r
Operating System
Linux/Unix, MacOS
Bug description
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]
Actual behavior
ArrayIndexOutOfBoundsException error
Expected behavior
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
Relevant log output
No response
Other information
No response
JGit should support X.509 signed commits
Description
JGit should support X.509 signed commits
Motivation
Companies have official X.509 certificates and they should be able to leverage existing certified identities
Alternatives considered
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.
Additional context
C-Git supports signed X.509 commits, therefore JGit servers (e.g. Gerrit) will have to deal with those signatures anyway.
JGit is very slow in marking the remote refs as advertised
Version
5.13
Operating System
MacOS
Bug description
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)
Actual behavior
Clone operation is slow
Expected behavior
Speed improvement in clone operation
Relevant log output
No response
Other information
No response
SSH-Agent-Proxy can't be used for users with .ssh/config IdentityFile entry
Version
6.8.0.202311291450-r
Operating System
MacOS
Bug description
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 IdentityFiles:
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;
}Actual behavior
The overridden JSch instance is thrown away.
Expected behavior
The overriden JSch instance should take precedence.
Relevant log output
No response
Other information
No response
Support public key in IdentityFile
Description
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:
- The public key is set as
IdentityFile(instead of the private one) - Then the SSH agent is used with https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent#section-3.6 and the given public key from the config only which will figure out the according private key for signing
(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)
Motivation
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
Alternatives considered
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.
Additional context
No response
Possible bug in MergeResult
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
Git clone failed with Krb5LoginModule error - JNA Library
Version
5.13
Operating System
Windows
Bug description
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
Actual behavior
Authentication should passed as expected. I tested seperately using git cli (same version) and it works fine.
Expected behavior
Issue should get resolved
Relevant log output
No response
Other information
No response
BouncyCastleGpgKeyLocator fails with ed25519 PGP keys
Version
6.8.0.202311291450-r
Operating System
Linux/Unix
Bug description
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
Actual behavior
Currently new PGPException("no q value found") is hit and operation fails.
Expected behavior
To have ed25519 key loaded up.
Relevant log output
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)Other information
No response
Add `restore` operation
Description
See https://git-scm.com/docs/git-restore
Motivation
Reference git implementation supports that.
Alternatives considered
No response
Additional context
No response
Pushing LFS objects to GitHub fails
Version
6.9.0
Operating System
Windows
Bug description
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.
Actual behavior
Pushing failes with the described message.
Expected behavior
Push succeeds and the LFS objects are properly pushed along with the pointer file.
Relevant log output
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'.Other information
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
JGit is unable to discover bitmaps on filesystem
Version
All releases from v4.10.* onwards
Operating System
Linux/Unix
Bug description
Context
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:
- Server-1 (read-only) has repo1.git bare repository
- Server-2 (read-only) receives repo1.git via rsync and stay in read-only until the transfer is complete
I do not see anything wrong with the above approach, as long as Server-2 is read-only until the transfer is complete.
Steps to reproduce the problem
- Rsync repo1.git repo with the exception of the bitmap
- run a git clone against Server-2 / repo1.git using Git/SSH
- Observe on the Server-2 in the sshd_log that the bitmap is not used
- Complete the rsync of repo1.git, which will transfer the bitmap
- run a git clone against Server-2 / repo1.git using Git/SSH
Actual behavior
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.
Expected behavior
At point 5. the sshd_log shows that the bitmap is used
Relevant log output
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
Other information
See Change 1174396
Upgrade to Apache MINA SSHD 2.12.0
Description
Upstream will release a new release 2.12.0 soon. Update the minimum required version in JGit to 2.12.0.
Motivation
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.
Alternatives considered
No response
Additional context
No response
org.eclipse.jgit.http.apache does not import javax.net.ssl!
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?
Jgit's diff3 is a curious mix of git's diff3 and zdiff3 styles
Version
6.9.0.202403050737-r
Operating System
Linux/Unix, MacOS, Windows
Bug description
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:
Base
a
b
c
d
Ours
a
H
E
c
d
Theirs
a
F
E
c
d
Actual behavior
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.
Expected behavior
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)?
Relevant log output
No response
Other information
See this helpful blog post about the differences between diff3 and zdiff3:
https://ductile.systems/zdiff3/
Support Java 8 Path API to allow using non-default filesystems
Description
JGit should support the Java 8 Path API as follows:
- All methods that accept
java.io.Fileinstances would be overloaded to also acceptjava.nio.file.Path. - Methods that take
Filearguments would be kept, but would usefile.toPath()and then call theirPathcounterparts. - Internally, JGit would only use the
PathAPI.
Motivation
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:
- When disk I/O is a bottleneck: with Jimfs, there is no I/O.
- When mechanisms against filling up the hard disk / docker volume add too much complexity: with Jimfs, one thread potentially gets
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!
Alternatives considered
- Set up a cronjob outside Java (e.g. "once per day, delete all directories older than a day")
- After completing a repo operation, schedule a cleanup task (e.g. "in 6 hours, delete this repo directory")
Both workarounds bring their own caveats and complexities.
Additional context
No response
Encountering LockFailedException: Cannot lock
Version
6.8.0
Operating System
Linux/Unix
Bug description
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
Actual behavior
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
Expected behavior
No errors and READ/WRITES should be successful
Relevant log output
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 omittedOther information
No response
Bugzilla migration incomplete
Version
default
Operating System
Windows
Bug description
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
Actual behavior
xyzzy
Expected behavior
xyzzy
Relevant log output
xyzzyOther information
xyzzy
JGit: tool execution return code: 127 when diff or merge due to error in CommandExecutor.createCommandArray() when Cygwin is on Windows Path
Version
6.8.0.202311291450-r
Operating System
Windows
Bug description
-
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.
Actual behavior
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
Expected behavior
The external tool should be launched for Git Diff or Merge without error
Relevant log output
No response
Other information
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.
[WARNING] unknown commit-graph chunk: 0x47444132
Version
6.7.0.202309050840-r
Operating System
MacOS
Bug description
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:
Actual behavior
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
Expected behavior
No warning.
Relevant log output
No response
Other information
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:
- Maven 4.0.0-alpha-10
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"
- Maven 3.9.6
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"
- Maven 3.8.8
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
NPE when calling RefDirectory:pack
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.
Remove outdated import-package in org.eclipse.jgit.gpg.bc
Version
6.10.0
Operating System
Linux/Unix, MacOS, Windows
Bug description
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).
Actual behavior
MANIFEST.MF contains this package import; the bundle resolution fails with BouncyCastle 1.78. C.f. eclipse-platform/eclipse.platform.releng.aggregator#1968.
Expected behavior
MANIFEST.MF does not contain this package import and bundle resolution against BouncyCastle 1.78 works.
Relevant log output
No response
Other information
No response
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.