Create Git Repositories for Plugins and Themes

  1. Ian Dunn

    The WordPress core, along with a few dozen plugins and themes, already have official and unofficial mirrors on Github, but they're sporadic and not always maintained. I think it'd be great to have official Git copies of the plugin and theme SVN repositories, to go along with the core repo that's already in place.

    I think building WP sites in a Git repo -- like Mark Jaquith's WordPress Skeleton project does -- is a great way to manage them, but you end up having some plugins/themes in a Git submodule, and others just as regular untracked files, because there isn't a Git copy of the SVN repo available.

    It seems like Git is becoming the de-facto standard for VCS, so there'll probably be more and more desire for something like this over the next few years. I'm already seeing developers use Github as their main repo, and then just copying into the WordPress.org SVN repo when they're ready to release.

    The copying from SVN to Git could be automated with something like svn2git. The Git repos could be on Github, or a new git.wordpress.org site could be created for them.

    Posted: 5 years ago #
  2. Justin Tadlock
    WordPress God


    I'm down with a git.wordpress.org.

    But, before we get into that, we actually need to discuss allowing theme authors any version control. Right now, theme authors are stuck uploading ZIP files while plugins have complete control via Subversion.

    Posted: 5 years ago #
  3. Ian Dunn

    Maybe this could be an opportunity to give theme authors version control. Instead of setting them up with SVN repos, though, just use Git from the beginning.

    But, even if that doesn't happen, I don't think the two necessarily have to be tied together. Git copies of plugin repos could be setup right now, regardless of what happens with themes.

    Posted: 5 years ago #
  4. Peter Wooster


    Is there an officially sanctioned way to use git-svn with the current WordPress plugin SVN repository. I've seen some articles online that recommend various workflows for this.


    Posted: 5 years ago #
  5. Ipstenu (Mika Epstein)
    Lead Plugin Wrangler


    Jaquith works on core, so that's as official as we get right now ;)

    Posted: 5 years ago #
  6. Peter Wooster


    Thanks Mike,

    I took a look at that and am going to give it a try, only copying my own plugin repositories.


    Posted: 5 years ago #
  7. Ian Dunn

    Alex King just wrote an article related to this topic, and suggested that the WordPress.org plugin repo have a meta field for plugins where the author could specific a URL for a Git repo.

    That kind of meta field could be used in this context, to tell the WP.org repo where to fetch tags and import them into WP.org SVN.

    He mentioned GitHub specifically, but there's no reason it couldn't be any publicly accessible Git repo.


    Posted: 5 years ago #
  8. Ipstenu (Mika Epstein)
    Lead Plugin Wrangler

    Sadly, we did SVN 'wrong' so there's a LOT that has to get kicked around with our repos for that to work :/

    Posted: 5 years ago #
  9. Rahul Bansal


    What do you mean by 'wrong`?

    If you mean we have used path-based access-control for plugin-folders rather than one SVN repo per-plugin-project then that can be fixed using a simple script wrapping around - https://github.com/nirvdrum/svn2git

    We have moved 100s of projects from SVN to GIT internally. svn2git is quite stable.

    One issue we may face is moving git access-control details. I guess we can either parse svn-rules to gitolite (assuming wordpress.org will use gitolite on public git-server) or simply scan each plugin-repo for commits. A person who had commit in SVN repo-path, will get write-access to corresponding git repo.

    If this idea ever goes ahead, I would like to contribute to it. Having worked on gitolite, svn2git projects - I think I might able to contribute my $0.02 :-)

    Posted: 5 years ago #
  10. Ipstenu (Mika Epstein)
    Lead Plugin Wrangler

    You'd have to ask Otto for the gory, details. The tl;dr is, according to SVN, we set up the plugin and theme repository 'wrong' and made it not as scalable as we could (iirc, each plugin/theme is not its own repo, but a folder of the extant ones). So yes, what you mention is a part of it. The other part is how many we have (50k), and not all of them want to or should be moved if, indeed, we move.

    Also keep in mind that we integrated logins and checkins with the front end pages you see on /extend/plugins. The login you use is the same for all of .org, we have to figure that out. Forum integration. All the cool new things we have with the headers and the reviews. We don't want to lose that, so we get to rewrite it?

    Plugin/theme review. Themes are integrated, plugins are not. How do we want to handle each of those? Mind you, that's a much bigger issue that just a different type of repository.

    Finally? What if we don't wanna go to Git? Not everyone likes it, or finds it all that 'simple.' Are we sure Thats the right solution for plugins/themes/core? Who is going to write the documentation for the handbook so people know how to submit patches?

    IMO, it's actually one of those things where it would be easier to just start over ;) and really that's not acceptable either.

    I'm not saying this is a bad idea, I'm saying this is a huge project that needs more thought and attention than a forum post oft provide. Someone needs to sit down and do more than pitch an idea at this point, and lay out options and suggestions with some code examples. Images too, to show what's going on.

    Posted: 5 years ago #

RSS feed for this topic

Reply »

You must log in to post.

  • Rating

    33 Votes
  • Status

    This is not a core suggestion