I get this Traceback, when entering a submodule (i tried with the cream/cream repo):
Traceback (most recent call last):
File "nano/nano.py", line 179, in __call__
retval = callback(environ, **kwargs)
File "/tmp/git/klaus/klaus.py", line 31, in wrapper
File "/tmp/git/klaus/klaus.py", line 159, in __init__
File "/tmp/git/klaus/klaus.py", line 122, in __init__
File "/tmp/git/klaus/klaus.py", line 184, in view
self['tree'] = self.listdir(self['path'])
File "/tmp/git/klaus/klaus.py", line 199, in listdir
for name, entry in self['repo'].listdir(self['commit'], path):
File "/tmp/git/klaus/repo.py", line 89, in listdir
tree = self.get_tree(commit, root)
File "/tmp/git/klaus/repo.py", line 85, in get_tree
tree = self[tree[directory]]
File "/usr/lib/python2.7/site-packages/dulwich/repo.py", line 996, in __getitem__
File "/usr/lib/python2.7/site-packages/dulwich/repo.py", line 270, in __getitem__
dulwich doesn't have submodule support yet. I don't think I can fix this, but I'll try to figure out a workaround.
Close #2: Support for binary files, includes explicit support for ima…
Also adds support for submodule changes in the commit diff view (#1).
Should at least print a nice error msg.
Maybe we can come up with simple submodule support. I.e. parse the .gitmodules file and "mount" the repos at the matching URL.
There's a parse_submodules function now
This doesn't require any further changes in Dulwich; the web UI needs to switch repository locations when it encounters a submodule.
Initial work on this can be found here:
This adds the right links, but it needs further work:
Cool! LGTM so far.
The problem with slashes isn't only Flask routing; it guess that shouldn't be too complicated. It's also that we don't necessarily have submodules in the internal Klaus.repos dictionary, which is a basename -> Repo object map. So if we were to use /toprepo/submodule/README.md style URLs and could figure out that this is actually accessing a file from submodule, we still wouldn't know how to resolve toprepo/submodule in the repository list, because even if submodule were in that dictionary, it would have the key submodule and not toprepo/submodule.
One solution would be to automatically add any submodules to the repository dictionary with their toprepo/submodule key, but don't show them on the repository list page. This requires to recursively look for submodules on initialisation for Smart HTTP support (unless we don't want to support Smart HTTP for submodules).
Another idea is to look for a top-level repository named submodule and assume that it must be the same as toprepo/submodule. As a sanity check, we could check if the submodule commit ID exists there. However this makes viewing different submodules with the same name impossible, unless we use a full dictionary scan for the commit ID, ignoring the repository name.
A third approach could work as follows: When initialising the repository dictionary, for each repository check if it's a submodule of another repository (this could be tricky) and add it to the repos dictionary both as submodule and toprepo/submodule. Then we could simply use the toprepo/submodule key into the dictionary list and could be sure we're getting the correct repository. We'd actually have to do this recursively for any combination of top/sub prefixes.
Not sure what's the best approach. Do you have other ideas?