Raw isen't working properly in gitlibt 1.6.2

[paladox]

Raw isen't working here https://git.wikimedia.org/raw/mediawiki/extensions/DeletePagesForGood.git/master/DeletePagesForGood.hooks.php since Wikimedia updated gitblit to 1.6.2 from 1.4.

configs set like

https://git.wikimedia.org/tree/operations%2Fpuppet.git/production/modules%2Fgitblit%2Ffiles

some files seems to work in raw https://git.wikimedia.org/raw/operations/puppet.git/production/modules!gitblit!files!gitblit.properties

[gitblit]

Yes, I see. There may be an issue resolving the difference between the "extensions" repo and the "extensions" subdirectory which DeletePagesForGood is part of. Actually, I'm surprised Gitblit is still in service at Wikimedia. I thought they jumped ship to Phabricator.

[paladox]

Yes they are in the process on moving to phabricator but gitblit will be discontinued once gerrit migrated to phabricator on Wikimedia..

How would the raw problem be fixed. Would updating to the 1.7 snapshot work.

[paladox]

Would it be because one of the configuations at https://git.wikimedia.org/tree/operations%2Fpuppet.git/production/modules%2Fgitblit%2Ffiles isen't updated or needs updated configs.

[gitblit]

The 1.7 snapshot probably won't help here because of the repo name - directory name collision. I think the problem you are observing here is there is a repo of the same name as a directory path (mediawiki/extensions).

When Gitblit parses /raw/mediawiki/extensions/DeletePagesForGood.git/master/DeletePagesForGood.hooks.php it will identify the repo by the first subpath match.

• is mediawiki a repo? if not....
• is mediawiki/extensions a repo? if not...
• is mediawiki/extensions/DeletepagesForGood a repo? if not...

Once it has identified a repo it then identifies the branch/ref followed by the path. This could be fixed by writing urls using the forward-slash-character from the settings (e.g. ! ) and properly parsing the repo from the url using this substitute - but that is not currently implemented.

I was not expecting users to create a repo and a subdirectory with the same name. I believe the raw problem (and likely other problems too) could be fixed today in that installation by renaming the mediawiki/extensions repo to not collide with the mediawiki/extensions/ directory. Of course such a change creates downstream turbulence - git remote configs, etc.

Gitblit should not have permitted this scenario in the first-place. But that's a tall-order since Gitblit allows you to administer repos and create your preferred directory structure manually without ever touching it's admin functions.

I haven't looked at Phrabricator much so I have no idea if it supports more than one level of repo subdirectories. Gitblit AFAIK is one of the only complete git hosts (maybe the only one?) that allows nested subdirectory structures. This capability complicates everything and creates interesting problems like this one. :)

[paladox]

Hi gitblit 1.4 supported this. It was when Wikimedia upgraded to 1.6.2 when the problem happended. and phabricator raw works properly.

[saper]

Yeah, it used to work and only raw action seems to be adversely affected.

Not tested really but maybe #950 helps a bit?

[gitblit]

I think the fix @saper wrote closes this issue.