|Re: [jgit-dev] public Repository class, internal FileRepository class, and Name/Identity|
I am working on enabling git:// support in Gitblit and integrating that
into it's security model and pre/post receive processing. I am also
listening to the discussion about Repository and FileRepository, GC,
WindowCache, etc for 3.0.0.
I have a need to identify a repository not by an object identity, nor a
canonical location, but by it's name. e.g. "myproject/tests.git".
When you look at JGit's Git servlet or JGit's Git Daemon, this name
(identity) is parsed from the url and used to find a local repository
(FileRepository in my case). The FileRepository ends up being mapped by
its canonical location - which when used with symlinks may or may not
have a relationship to the originally requested repository name. The
originally requested name (id) is discarded during this process.
When the JGit servlet's pack factories are created, the
HttpServletRequest is provided as a parameter to the pack creation
methods and the requested repository name (id) can be re-extracted from
the servlet request url. This is how Gitblit currently works-around the
missing repository name information.
Unfortunately for the Git Daemon there is no url to parse in the
I have identified a few workarounds - none of which I am in love with -
to get that information including:
1. Subclass FIleRepository and add a field. (doesn't seem like a great
idea since JGit wants to mark this class as internal and is encouraging
indirect use of this class)
2. Subclass FileResolver, abuse StoredConfig, and inject the requested
repository name as a temporary setting to be retrieved in the pack
factories/hooks later on. Abusive and sneaky, but fits within the API
and does not add new subclasses.
3. Maintain a (Repository object or canonical location)<->name lookup
table in Gitblit. Fits within the API and does not add new subclasses,
but adds complexity.
This leads me to wish that the Repository class, itself, had a name/id
property that was set by JGit based on the requested repository name.
This name property would be useful to Gitblit and could be useful to
other JGit-based server implementations. I imagine that a JGit-based
client, like EGit, probably would not find that property useful at all.
And that is the dilemma: do you add properties/methods to common objects
to help the downstream server-side eco-system or do you maintain strict
abstractness and say that a property which is not common to both client
and server so has no business in the common object?
If there is resistance to adding a field like that to Repository, does
anyone have another suggestion on how to preserve the requested
Back to the top