Community
Participate
Working Groups
While creating a bare repo, following line throws a NoWorkTreeException: new RepositoryBuilder().setGitDir(file).setBare().build().create(); There exists a workaround, i.e. calling create function with 'true' argument, but it seems redundant since it should have been already settled with setBare method call. I think the problem is create method of BaseRepositoryBuilder which should call create(isBare()) instead of create(false). Same behavior is observed with FileRepositoryBuilder as well which is not a big surprise since it is inherited from BaseRepositoryBuilder like RepositoryBuilder.
I was also surprised by this behavior. I agree that the main problem is that the multiple Repository.create(...) methods don't look at the "bare" attribute of the repository. Problem is: how to solve this without breaking existing clients? The JavaDoc of the method Repository.create() which you call is very explicit: "Repository with working tree is created". We cannot change this behavior without potentially breaking existing code. What I could do is to add another Repository.createXYZ method which uses the bare attributes to decide whether the repository is bare or not. Currently I struggle to find a good name for such a methdod. Would this help?
(In reply to Christian Halstrick from comment #1) > I was also surprised by this behavior. I agree that the main problem is that > the multiple Repository.create(...) methods don't look at the "bare" > attribute of the repository. Problem is: how to solve this without breaking > existing clients? The JavaDoc of the method Repository.create() which you > call is very explicit: "Repository with working tree is created". We cannot > change this behavior without potentially breaking existing code. What I > could do is to add another Repository.createXYZ method which uses the bare > attributes to decide whether the repository is bare or not. Currently I > struggle to find a good name for such a methdod. Would this help? Thanks for the comment. Of course your proposal would help and be better than current case. But i think the main problem is that the current implementation of the create function, including the javadoc, contradicts with the arguably expected behavior of respecting builder options. And i also think, that's the exact reason why it's hard to come up with a proper method name, since the name canditates i can think of are just pleonastic ones such as "createAccordingToBuilderOptions". I still believe this issue can be fixed without compromising backwards compatibility by using appropriate defaults, assuming that no one would "explicitly" set bare builder option and expect the create function to create a non-bare repo. If that assumption makes sense, an approach might be to add a "bare" attribute in Repository class, just like the one in BareRepositoryBuilder, which is "True only if the caller wants to force bare behavior.". jgit/org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java public abstract class Repository implements ... { ... /** True only if the caller wants to force bare behavior. */ private boolean bare; ... protected Repository(final BaseRepositoryBuilder options) { ... bare = options.isBare(); ... } ... public void create() throws IOException { create(bare); } ... }
You convinced me. The behavior we document for Repository.create() looks so broken to me that changing that behavior is more a fix than an API breaking change. And the clients we may break (clients who call setBare() on a Repository but expect a non-bare repository to be created during create()) hopefully don't exist in real life. Do you want to propose the change in gerrit?
(In reply to Christian Halstrick from comment #3) Sure, i can absolutely do that as soon as i write some decent tests for it.
New Gerrit change created: https://git.eclipse.org/r/61532
