Git repos location

Kamil Paral kparal at redhat.com
Thu Jan 23 10:48:00 UTC 2014


> https://phab.qadevel-stg.cloud.fedoraproject.org/
> 
> The hosting does work over ssh, but I'm noticing some quirks
>  - the ssh urls are displayed incorrectly. This may be fixed in the
>    latest upstream (the version we're using is several weeks old) but
>    I haven't checked yet. For the dummy repo I created:
>    * shown:
>       ssh://phab.qadevel-stg.cloud.fedoraproject.org/diffusion/PON/
>    * actual thing to clone if you want it to succeed:
>       git at phab.qadevel-stg.cloud.fedoraproject.org:diffusion/PON
> 
>  - http hosting doesn't work yet. I have some more tweaking to do in
>    order to get that functional but it's do-able

Does this mean that phab repos can't be accessed publicly at this moment? What about public git:// access, is that supported/working?

Does the http hosting require fixing some bugs, or is it purely a configuration issue?

> 
>  - The repo names are ... weird. I understand why they end up like they
>    do, but I was hoping the uris would contain the repo name, not the
>    callsign.

That's a bit unfortunate. Does it mean that we need to differentiate all our repos by 4-letter access codes?

That would also mean that people cloning the repos need either provide a reasonable name to the git clone command, or they'll end up with cryptic directory names for our projects.

> 
> The setup is pretty straightforward and doesn't really mess with the
> git hosting itself - just injects phabricator into the ssh auth
> mechanism in a similar way to how gitolite works. If we did
> decide to go this route for code hosting and something did go
> horribly wrong, we have backups of the raw repos and it would be
> pretty easy to resurrect them outside of phabricator.
> 
> Another feature that I haven't looked at much is mirroring - you can
> configure repos to push commits to a remote repository. The advantage
> here is that we could have the canonical upstream under our control and
> have bitbucket/github mirrors that other folks could use to create
> diffs from.

This might be a very good idea. We can use our system while the public can easily find and access our code, fork it, send a pull request.

Or, if we find git hosting in Phab unsatisfactory, we can do it the other way round - host code on Github/Bitbucket and clone to Phab (if it helps something, for example reviews).

When it comes to Github/Bitbucket choice, I played with them a bit and both seem pretty equal. They are closed-source, they support teams, and because we won't need issue tracking there's not many other differences. Only Github is more popular and more people have an account there, so I think that would be the only reason to pick Github over Bitbucket.


More information about the qa-devel mailing list