How do I release file system locks after cloning repo via JGit
Asked Answered
D

2

13

I am playing around with cloning a remote existing repo with jGit following the guide here:

https://github.com/centic9/jgit-cookbook/blob/master/src/main/java/org/dstadler/jgit/porcelain/CloneRemoteRepository.java

I'm using CFML for my example:

Git = createObject( 'java', 'org.eclipse.jgit.api.Git' );

localPath = createObject( 'java', 'java.io.File' ).init( expandPath( 'temp' ) );

result = Git.cloneRepository()
        .setURI( 'https://github.com/github/testrepo.git' )
        .setDirectory( localPath )
        .call();

result.close();

The clone works great, but file locks are not released on "pack" files inside temp\.git\objects\pack until I stop the Java process.

Then I also noticed the API docs seem a little wishy-washy concerning the behavior of the result's .close() method.: http://download.eclipse.org/jgit/site/4.0.1.201506240215-r/apidocs/org/eclipse/jgit/lib/Repository.html#close()

Decrement the use count, and maybe close resources.

Maybe? What's that supposed to mean? What do I need to do in order to "relinquishing any underlying resources" as specified in the AutoCloseable interface that the .close() method helps implement?

There are a couple of similar questions on SO, but none of them involve using the static method on org.eclipse.jgit.api.Git to clone a new repo.

Diacid answered 1/8, 2015 at 17:29 Comment(0)
D
13

So literally as I was clicking submit on this after a couple days of poking I stumbled across what I believe is the answer.

The cookbook example only calls the .close() method on the result of the cloneRepository()'s call() method (A Git instance). The API docs state that method should also call the .close method of the underlying Repository instance:

http://download.eclipse.org/jgit/site/4.0.1.201506240215-r/apidocs/org/eclipse/jgit/api/Git.html#close()

If the repository was opened by a static factory method in this class, then this method calls Repository.close() on the underlying repository instance.

However, I found that if I get the Repository instance myself and call its .close() method, all file system locks are released. I assume this is an omission in the JGit cookbook reference I was following and will submit an issue/pull.

Here is the working CFML code. Note the two .close() calls at the bottom now.

Git = createObject( 'java', 'org.eclipse.jgit.api.Git' );

localPath = createObject( 'java', 'java.io.File' ).init( expandPath( 'temp' ) );

result = Git.cloneRepository()
        .setURI( 'https://github.com/github/testrepo.git' )
        .setDirectory( localPath )
        .call();

result.getRepository().close();
result.close();
Diacid answered 1/8, 2015 at 17:29 Comment(5)
So it also is either a bug in either the Git.close() method or its javadoc, maybe you can also raise an issue there to get it corrected/clarified?Radix
I've love to raise an issue with jGit we well if this is actually a bug in the library (and not just an incomplete example). I'll make a note to do that later today.Diacid
Yes, I took a quick look, I think there is a small bug in CloneCommand.call(), it should pass "true" as additional parameter when constructing the instance of the Git object to make the closing work as advertised, see also git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/…Radix
Additionally, errors during fetch and checkout in that method will leave the repository object unclosed...Radix
Thanks for checking that out. I put in a ticket for jGit here: bugs.eclipse.org/bugs/show_bug.cgi?id=474093Diacid
Q
0

I struggled with that as well. Here is how I solved this.

CloneCommand cloneCommand = Git.cloneRepository();
URIish urIish = new URIish(getVersionControlPath().toString());
cloneCommand.setURI(urIish.toString());
Date date = new Date();
String testgit = "testgit_" + date.getTime();
cloneCommand.setDirectory(getVersionControlPath().getParent().resolve(testgit).toFile());
Git call = cloneCommand.call();
call.close();
Quaternity answered 18/4, 2021 at 12:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.