Page MenuHomePhabricator

Clones from git.wikimedia.org are not redirected
Closed, DeclinedPublic

Description

If someone had cloned a repository from gitblit, when trying to pull from it they will encounter an error like the following:

fatal: https://git.wikimedia.org/git/mediawiki/skins/MonoBook.git/info/refs not valid: is this a git repository?
fatal: https://git.wikimedia.org/git/mediawiki/skins/Vector.git/info/refs not valid: is this a git repository?

Currently those urls lead to a «The requested project does not exist» page.

They should probably redirect to gerrit:

https://gerrit.wikimedia.org/r/mediawiki/skins/Vector.git

Related Objects

StatusAssignedTask
ResolvedQgil
ResolvedQgil
ResolvedQgil
Resolved RobLa-WMF
ResolvedQgil
Resolveddemon
DeclinedNone
DeclinedNone
ResolvedDanny_B
ResolvedPaladox
Resolveddemon
Resolveddemon
ResolvedTerraCodes
ResolvedPaladox
Resolveddemon
DuplicateNone
ResolvedQgil
Resolvedmmodell
Resolvedmmodell
Resolvedmmodell
Resolvedchasemp
Resolvedmmodell
Resolvedmmodell
Resolvedmmodell
Resolvedchasemp
Resolvedmmodell
ResolvedQgil
DeclinedNone
InvalidQgil
ResolvedQgil
DeclinedNone
Resolved yuvipanda
Invalidchasemp
Resolvedvalhallasw
Declinedvalhallasw
Resolvedvalhallasw
ResolvedLegoktm
ResolvedLegoktm
ResolvedLegoktm
InvalidLegoktm
DeclinedNone
DeclinedNone
DeclinedNone
InvalidQChris
ResolvedNone
DuplicateNone
DeclinedNone
DeclinedNone
Resolvedgreg
Resolvedgreg
Resolveddemon
Resolvedgreg
DeclinedNone
Resolvedgreg
Invalidgreg
DeclinedNone
DeclinedNone
Declinedmmodell
Resolvedgreg
Resolveddemon
Invalidmmodell
DuplicateNone
Resolvedmmodell
DeclinedNone
Resolvedmmodell
Declinedgreg
Invalidgreg
DeclinedNone
ResolvedQgil
Invalidmmodell
Resolvedgreg
Resolvedgreg
Declinedgreg
DeclinedNone
Resolvedchasemp
Resolveddemon
Resolvedchasemp
Resolvedchasemp
Invalidchasemp
Resolveddemon
ResolvedNemo_bis
Resolveddemon
ResolvedPaladox
ResolvedKrenair
Resolvedmmodell
InvalidNone
DeclinedNone

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJul 1 2016, 9:25 PM
Danny_B triaged this task as High priority.Jul 1 2016, 9:26 PM
Paladox added a subscriber: Danny_B.Jul 1 2016, 9:26 PM
Paladox added a subscriber: Paladox.

Actuall good idea @Platonides didn't think about gerrit thanks for the suggestion.

@Danny_B would you be able to do that please.

/git/ will need redirected which is it's clone link.

please.

@Platonides Please provide example of URL used to clone, thanks.

greg added a subscriber: greg.Jul 1 2016, 9:37 PM

Why change to gerrit instead of diffusion? Presumably they weren't pushing to gitblit and it was just for using/deploying the software (not developing it); or, they at least added the gerrit remote to do that (push to gerrit).

My vote would be to change to Diffusion (instead of Gerrit) for https clone urls. We don't want to have to update these yet again when we migrate away from Gerrit :) What downsides did I miss?

Paladox added a comment.EditedJul 1 2016, 9:39 PM

@greg since in diffusion we have a mix of callsigns and then takes the short name

So for example for mediawiki it would be like

https://phabricator.wikimedia.org/diffusion/MW/mediawiki.git

MW is the callsign and mediawiki is the short name

It would be hard to get it to work with diffusion as clone links, since all projects have different short names.

I suppose we can do what we did for gerrit and create redirects like if the url matches for example /mediawiki/core/ it can be redirected to https://phabricator.wikimedia.org/diffusion/MW/mediawiki.git

@greg I think it's better to use gerrit for consistency. All clones going through gerrit, instead of some of them being done through phabricator. Easier too should they later want to switch it to a ssh:// url.

Moreover, diffusion copy of the repository may not be completely up to date.

@Platonides all repos in diffusion are updated correctly since there mirrored from gerrit.

Or we can get upstream to support some type of customised cloning link.

Paladox moved this task from To Triage to Backlog on the Gitblit-Deprecate board.Jul 1 2016, 9:47 PM
greg added a comment.Jul 1 2016, 9:51 PM

@greg I think it's better to use gerrit for consistency. All clones going through gerrit, instead of some of them being done through phabricator.

That ship sailed when we introduced Gitblit alongside Gerrit. There has always been inconsistency. Now we have Diffusion and Gerrit. And at some point only Diffusion.

Easier too should they later want to switch it to a ssh:// url.

ssh:// urls are supported in Diffusion, but (obviously) less useful if the repo isn't using Differential for code-review :)

But, my original point was potentially in the category of premature optimization.

Paladox moved this task from Backlog to In Progress on the Gitblit-Deprecate board.Jul 1 2016, 9:52 PM

@greg since in diffusion we have a mix of callsigns and then takes the short name
So for example for mediawiki it would be like
https://phabricator.wikimedia.org/diffusion/MW/mediawiki.git
MW is the callsign and mediawiki is the short name
It would be hard to get it to work with diffusion as clone links, since all projects have different short names.
I suppose we can do what we did for gerrit and create redirects like if the url matches for example /mediawiki/core/ it can be redirected to https://phabricator.wikimedia.org/diffusion/MW/mediawiki.git

It might not be that difficult as it seems, however, it requires not only rewrite rules, but also some changes in Phabricator's GerritProjectController.
As in previous case of redirecting Gitblit, a list of possible origins and destinations types would be handy.

I don't have that much time to work on rewrite rules until it is finally decided, what will be the target. If Gerrit or Diffusion or Differential or whatever...

Once you guys decide on that, I'll be happy to jump in and write those rules, but ATM, I can't afford working on something which will later on turn to be finally rejected in favour of something different.

As nobody is obviously working on it yet (and perhaps won't until the decision on targets will be done), it should stay in backlog.

@Danny_B I think we could do diffusion but we should do what ever is easy at first and then long term would be doing the hardest.

IMO this should redirect to diffusion using the existing mappings that we already have set up in rPHEX phabricator-extensions

saper added a subscriber: saper.Jul 20 2016, 9:30 PM

I just run into this today by adding this to my composer.local.json:

`
{
    "require": {
        "mediawiki/vector-skin": "@dev"
    }
}
`

It ends up with

`
[RuntimeException]                                                                                                                                                               
  Failed to execute git clone --no-checkout 'https://git.wikimedia.org/git/mediawiki/skins/Vector.git' 'skins/Vector/' && cd 'skins/Vector/' && git remote add composer 'https://  
  git.wikimedia.org/git/mediawiki/skins/Vector.git' && git fetch composer                                                                                                          
  Cloning into 'skins/Vector'...                                                                                                                                                   
  fatal: https://git.wikimedia.org/git/mediawiki/skins/Vector.git/info/refs not valid: is this a git repository?                                                                   
`

Shall I open another bug to update packagist.org entry or entries?

Yes please.

This will require us to generate another list to go on due to the difference in the names.

jayvdb added a subscriber: jayvdb.Aug 11 2016, 4:07 PM

I just ran into this, via a sysadmin who was previously using git branches to keep his wiki extensions stable.
Has there been a Sysadmin-notice about this?

If someone from Release-Engineering-Team or Operations or whoever else relevant would wrap up where it should be redirected, including some examples of original URLs and Phabricator redirection urls (/r/p/...) [as it seems that the new desired target should be Diffusion instead of Gerrit] then I can finaly start work on that.

Paladox added a comment.EditedAug 18 2016, 11:43 AM

I think for example the original link for mw core would be

https://git.wikimedia.org/git/mediawiki/core.git -> https://phabricator.wikimedia.org/diffusion/MW/mediawiki.git

But we will need to also simplify the clone links since our script only does callsigns not callsign and name.

Maybe we want to do something like /r/clone/MW.git ?

@mmodell ^^ please?

@Danny_B , that wikitech-l post doesnt indicate that people's LTS release
branch clones are going to break.

demon added a subscriber: demon.Oct 24 2016, 10:23 PM

To be honest I think we should allow the clones to break.

hashar closed this task as Declined.Oct 25 2016, 9:34 AM
hashar added a subscriber: hashar.

Agree with Chad. Cloning from git.wikimedia.org has been broken for age and AFAIK has never been advertised as a way to clone. Either Gerrit or Diffusion use different URL. I have 100% confidence that developers having the issue will now how to switch, for the few power user that runs MediaWiki from git clone/branches, I am confident they can switch easily as well.

At worth, we will have a few support requests to handle, way easier than trying to add some back compatibility layer for some hypothetical use case.

I totally agree with @demon and @hashar on this one. Glad to lay this to rest.

jayvdb added a comment.EditedOct 25 2016, 8:52 PM

@hashar , this isnt about developers, or power user. I encountered this because a MediaWiki sysadmin had a broken install and wasnt able to fix it because of this. He had quite sanely checked out the 1.23 stable branch and updated it periodically.