My Gitorious projects have moved.

Gitorious – which I preferred to GitHub for being totally open-source – is shutting down sometime in May. I had no fewer than 26 projects on there, including reposurgeon, cvs-fast-import, doclifter, and INTERCAL.

Now they’ve moved. This won’t affect most of my users, as the web pages and distribution tarballs are still in their accustomed locations at catb.org. If you’re a committer on any of these Gitirious repos, of course, the move actually matters.

Temporarily the repositories are on thyrsus.com; here’s the entire list. They may not stay there, but moving them to thyrsus.com was 90% of the work of moving them anywhere else and now I can consider options at my leisure.

36 thoughts on “My Gitorious projects have moved.

  1. Are the repositories still publicly accessible (besides from gitweb)? There’s no URL listed for them, and I can’t seem to make any good guesses for it.

    • >Are the repositories still publicly accessible (besides from gitweb)? There’s no URL listed for them, and I can’t seem to make any good guesses for it.

      There are clone URLs on the project web pages. I’m working on getting links to those pages into the gitweb view.

    • >So far, so good — but they don’t seem particularly cloneable at the moment:

      Shit. And I can’t test the anonymous case because it has my credentials. So, how do I write a reference that can be anonymously cloned from? The repo collection is under gitolite control.

  2. Yeah, those are SSH URLs. I’m not sure if it’s possible to get passwordless/keyless access over ssh…

  3. Looks like one of the simplest methods would be simply having the repositories available to your Apache process. You can also setup a git-daemon for it. See git-http-backend and git-daemon documentation. (I’ve never done the HTTP setup myself, but it shouldn’t be difficult)

    I did some research, seems gitolite is not meant for anonymous access.

    • >You can also setup a git-daemon for it.

      Yeah, I figured out how to do that. Tomorrow I’ll regenertate all the pages with both ssh and git-protcol links.

  4. >”When you run your own servers you never have to worry about these things. Server huggers, represent!”
    Yea but then you get hacked, your server is never fast enough to keep up with demand, etc.
    If you say the wrong thing people will try to hack your servers, report you to the police,
    do anything they can (except meet you face to face)

    That’s why people don’t do it. Also linux has a root exploit every release, it’s not
    secure at all, it only starts to appear to be if you patch it with grsecurity/pax.
    Now we have systemd taking over everything and destroying the simple(r) unix like OS
    we knew, and that has root exploits aswell, (and buffer overflows even in it’s login)

    So why bother. There’s no pride in these edifices any longer.

    ESR: where can one annouce opensource software releases after freshmeat betrayed us?
    I want to announce a new release of this game: http://www.lgdb.org/game/chaosesque-anthology
    but where can it be done? You noted you were going to make a new version of freshmeat
    some time ago.

    • >You noted you were going to make a new version of freshmeat some time ago.

      Not me; there’s a guy working on it I intended to help. We lost contact, I must look him up again.

  5. > anonymous case because it has my credentials. So, how do I write a reference that can be anonymously cloned from?

    While you are at it please provide also a http: clone URL and service. And you can test http: clone yourself with no excess credentials in the way.

    Looks like gitweb itself does not provide that and you must configure the web server to expose project.git/ directories beside the gitweb.cgi.

    Re: how to announce URLs at gitweb google://git_base_url_list

    • >Where does the name thyrsus come from?

      Greek. A thyrsus (or thyrsos) is a pinecone-tipped staff used in the rites of Pan and Dionysius.

  6. This may be somewhat off-topic, but I wonder if the forge problem and Git hosting problems can be solved by the same software. Something that has somewhat bugged me about GitHub and the like is that there is still some small lock-in related to the issues tracker, and to a lesser extent, the releases themselves. Perhaps a solution could be found where the issues tracker itself is just another branch of the main repository, and other details are stored in-repo as well (maybe someone’s already tried this?). I’m thinking more on the terms of fossil, but I don’t think git is ill-suited by an special property of it; git also has a lot of inertia and UI familiarity behind it that fossil sorely lacks.

  7. @esr –

    > >So far, so good — but they don’t seem particularly cloneable at the moment:

    > Shit. And I can’t test the anonymous case because it has my credentials.

    So? Create another user on ‘bitty-box’, don’t give it any keys, test with it.

    I told you it would be useful someday. ;-}

  8. @Mike_Swanson: there have been numerous attempts to put an issue system into distributed, with more or less success: google ‘distributed bug tracking’ and find projects like BugsEverywhere and Ditz .

    The problem seems to be (as always) buy-in. Ideally a forge would add support for some project so that there would be both CLI and web-gui ways to poke at bugs – CLI for the devs, web-gui for users/managers/people-without-a-cloned-repo.

  9. FYI while GitHub:FI (or whatever the name now) is closed source, GitLab (which takes over Gitorious) has GitLab Community Edition, which is open-source (I think, as it does not use any common license, but its own: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE)

    Nb. you could self-host Gitorious-the-code…

    Gitolite has some support for HTTP(S) access, which I think is required for anonymous access to repository; though perhaps there is ‘guest’ SSH user possible… though Gitolite is all about key-based authentication.

  10. @PJ –

    > The problem seems to be (as always) buy-in.

    Um, partly. Partly also because you want one canonical “list o’ bugs”, so that everyone involved in the reporting-verifying-diagnosing-fixing-testing loop can track them coherently and simultaneously.

    As is often the case, our host has blogged about this before.

  11. @John_D_Bell

    One Source of Truth is mom and apple pie. That doesn’t keep that source from being distributed via ‘git fetch’, though.

    As the post you pointed to points out, though, to an extent this is just shoehorning issues into a DVCS as a ‘sweet technical hack’. In this case (and in the case of a wiki as well), I think it’s worth it not necessarily because I think it’s all that natural a fit for a bug tracker (though it’s pretty dang natural for a wiki, esp. if it’s its own branch), but because I want as much project data as possible in one place, and the DVCS is the most general of the pieces.

  12. @PJ –

    > … but because I want as much project data as possible in one place, and the DVCS
    > is the most general of the pieces.

    I think what you really want is an integrated forge, which contains a DVCS (for the code), a wiki (for the documentation), a mailing list handler (with web view), and a bug tracker (which may be a specialized part of the wiki, but maybe not). Yes, you do want them all in one place, with full data import/export, with the ability to federate it with related projects, scriptable, clonable, etc. The whole enchilada.

    When we get enough Round Tuits, we’re working on it. :-) I’m sure Eric would not turn down assistance.

  13. @John_D_Bell –
    >I think what you really want is an integrated forge […]

    …sort of? The nice thing about keeping it all in a DVCS is that it forces a serialization format, which becomes the data abstraction layer allowing multiple interfaces: CLI, GUI, web, whatever. Ideally, one could retarget known-good user interfaces (ala github) to such a backend.

    As for working on it… possibly… but I can’t seem to find any code to contribute to…

  14. @PJ

    Roundup is the code base. The last blog post I linked to describes what Eric thinks needs to be added. (I’m personally going to try to work on the “repo class” part, when I get my Python skills up-to-par, and enough nanoseconds to make it worthwhile.)

  15. One of the things that concerns me with regards to where the issue tracker is, is how tied into a particular service it might be, which gave rise to my ideas of sticking it into a DVCS branch itself. The benefits of seeing them offline might be negligible, but not having a panic when any particular service closes its doors is a huge benefit. It doesn’t even necessarily have to be closed doors, it can be on idealism like esr rejecting a move to GitLab.

    Much of my stuff is on GitHub, and while they have public repositories clonable for a surprising number of things, like web sites and wikis, the issue tracker remains somewhat behind closed doors — you can use an HTTP and JSON API to talk to it, but that’s nowhere as efficient as a repository could be. It might be accidental, but I’m more inclined to believe it was a tactical decision: by making moving out of GitHub just that much more complicated, it discourages people from doing so. I happen to not agree with this practice, but it is very common.

  16. On a topic closely related to preferring open source version control, I think Jeff Atwood fundamentally misunderstands where esr is coming from, what esr believes, and what esr is attempting to accomplish:


    But what’s the long term answer to the general problem of not enough eyeballs on open source code? It’s something that will sound very familar[sic] to you, though I suspect Eric Raymond won’t be too happy about it.

    Money. Lots and lots of money.

  17. It seems Jeff Atwood simply didn’t do his research and likes to attribute thoughts to ESR that he assumes must be true… because open source means people don’t get paid? I don’t know *shrug*. Most of his post seems to be going on about some big revelation that people like to get paid for their work. I’m not really sure what century he thinks he’s living in :D

  18. @Mike Swanson:

    > Most of his post seems to be going on about some big revelation that people like to get paid for their work.

    Well, at least he gets that partially right. The weird misconceptions that it would somehow be possible for there to not be a global free market in security bugs, and that we all have the same goal of making software more secure, maybe not so much.

  19. Eric, as you contemplate the future of open source hosting, I ask you to compute my logic against your past stance that anonymity is counter-productive (presumably because you think reputation is so critical in the Magic Cauldron of open source). Hey reputation can be attached to pseudonyms.

Leave a Reply

Your email address will not be published. Required fields are marked *