Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Idea: move build script to a dedicated repo #826

necolas opened this Issue · 22 comments

7 participants


An idea. Might be a terrible one.


  • The build script is a useful project in its own right.
  • A repo dedicated to the build script(s) could help bring in more contributors.
  • Might be easier to update the build script across projects. Among the h5bp projects alone, we have 3 separate repos that use the build script. At the moment they all need manual updating.
  • Like the server-config repo, maybe this could become a place to find one of several build scripts...whichever is suitable for your project.


Not entirely sure but this could be doable using git-submodule or git-subtree, which is what solarized uses to keep all its repos synced in one master repo.

One possibility would be to have each build script in it's own repo but synced in the master 'build-scripts' repo. That way you can include any one build script in your project.


  • Referencing a remote repo but also customising it to work with a project's directory structure?
  • Up-front cost of moving.
  • (other)

What do @mklabs, @KushalP, @roblarsen, and anyone else helping out with the build scripts or working on the project think?


I think it's a great idea, especially if it kick starts my longstanding wish to have multiple build solutions available for the project. But even if it doesn't and it's just centered around the ant script, I think it would be cool to have a focused place to tinker with it.

I've never managed git submodules through a github repo, so I don't know how much overhead there would be at that end, but as an end user they're no big deal and would do exactly what you imagine.


yes, good idea since i am mainly interested in the build
on top of that one could again make some packages as bundled submodules plus some magic that would combine the plate, the build and whatever fits in there


I'm definitely +1 on this too.

It'll probably get much easier to work with build scripts. Maybe another benefit I see with that move would be to make the main repo smaller.




(I keep waiting for someone to burst in and object ace attorney style)

Otherwise, is this a go?


Looks like it. Shall we start planning out how we might organize things and how it will work in practice?


that sounds like a good next step, especially since some of the plumbing is important to get right- technically and from an ease-of-use perspective


These articles look relevant to what we're trying to do:


Playing around with this a little bit today Splitting a subpath into a new repo was straightforward.

I started looking at the subtree merge strategy- can someone git-smarter than I am explain the benefits for both the repo owner and consumers of that over simply doing a submodule?


Rob, I found some handy explanation about git-subtree:

How does this seem like it would compare to your experience with submodule?


Reading that, it looks like it would be even easier for end users, which is good. With submodules, end users have to actually pay attention to the fact that there are submodules.


There appears to be an overwhelming +1 on this, but I'll add one more :)

imo developers would greatly benefit from having a solid built script they can refer to as a base for projects. To date I've been pointing them to the H5BP one + wiki, but something a little less project-specific would be great.

@roblarsen do you have plans on taking another look at the work in soon?


I've been planning on it, yeah. I've had a big-ass writing deadline that's taken up my whole month, but that's winding down this week. I'm assuming everyone is comfortable with the subtree plan? From the perspective of the new repo it's a no-brainer.


I just looked back at this previous comment and I realized I wasn't being clear. While I'm comfortable with the new repo part, I want to make sure @paulirish and the rest of the folks who maintain the main @h5bp project are comfortable with whatever solution we come up with the keep the two projects linked. I mean, we can clearly just start work on the separate repo starting Monday or whatever. That's a no-brainer. I just want to make sure everyone is comfortable with the solution we come up with to keep the two projects linked. I'm not enough of a git guru to walk through what an actual best practice here (paging a git guru)

Long story short, I'm good with moving ahead on the new repo and hopefully everyone else is good with whatever plumbing we need to do to keep everything synced.

Now... I'm going to go XMAS it up for two days.


i don't think a submodule would be all that bad in this case, but i'm curious about the subtree as well.
i guess let's proceed with subtree as it seems to have a slight advantage


This is one of the priority issues IMO. From the sound of things, subtree would be easier for the move, for users, and for syncing various build scripts in one repo and one build script in the h5bp repo. Might be worth pinging Ethan (Solarized), who has done this before...or double checking with someone who knows their git to see if this is a good plan.


+1 on pinging a git genius.


I'm confident enough in subtree for us to move forward on this now. :)
@roblarsen do you want to touch base with either ethan or apenwarr in order to confirm any thoughts?



Will be handy for managing the combined build script repo, and for pointing people to when they want to merge a build script repo into h5bp.


I'm probably as available to work on this right now as I'll ever be, so if we want to move forward with this starting... today or whatever, I'm already rolling up my sleeves.


That would be great. Are you happy with this solarized-like approach:

One possibility would be to have each build script in it's own repo but synced in the master 'build-scripts' repo. That way you can include any one build script in your project

@necolas necolas closed this issue from a commit
@necolas necolas Remove ant build script. Close #826
The ant build script is now in a separate, dedicated repo at:
@necolas necolas closed this in f96fed6
@mikealmond mikealmond referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.