Ah, cheers, owensd. I'm more thinking about how those standard community versions will be maintained, though. The platform layer files – i.e. xcb_handmade.{cpp,h} – will be safe but if, for some reason, any of the other files from HMH proper need to be edited for compatibility, these will end up being overwritten when Casey pushes, right?
I just remember someone flipping the Y-axis in the game code because they couldn't figure out, as I couldn't either, how to do it in the XCB platform layer code. Without the flip, the game gets drawn upside-down.
Am I right in thinking that submodules will not easily allow us to edit the community versions of the files Casey edits without them being overwritten? If so, do you know if git has a way of letting us do this? Or, are we not bothered about doing it at all?
I just remember someone flipping the Y-axis in the game code because they couldn't figure out, as I couldn't either, how to do it in the XCB platform layer code. Without the flip, the game gets drawn upside-down.
Am I right in thinking that submodules will not easily allow us to edit the community versions of the files Casey edits without them being overwritten? If so, do you know if git has a way of letting us do this? Or, are we not bothered about doing it at all?
Submodules suck when you try to use them to actively contribute within those. However, as a basic dependency manager, they work just fine. That's what we're talking about here.
I want to use an OS X port, I'd something something like this:
At this point in time, I'd have something that looked like this:
Make your modifications as you see fit. You won't be modifying anything within the handmadehero code at all.
This requires a couple of changes to the build file, namely:
That's the basic idea. The benefit of this approach is that it doesn't require daily maintenance for this to work as long as the submodule is tracking the branch. Of course, this could bring in compiler errors from breaking changes in the platform layer.
There's not perfect solution for this. This is just one way that would work and have low overhead for all involved.
I want to use an OS X port, I'd something something like this:
- git clone https://github.com/HandmadeHero/osxrepo.git (not a real URL, just an example)
- git submodule update --init
At this point in time, I'd have something that looked like this:
1 2 3 4 5 6 | osxrepo/
handmadehero/ -- This is Casey's code
code/ ...
misc/ ...
code/ -- This is the OS X code
misc/
|
Make your modifications as you see fit. You won't be modifying anything within the handmadehero code at all.
This requires a couple of changes to the build file, namely:
- Replacing the win32_ file references with the platform.
- Adding the handmadehero as part of the include path for the compiler.
That's the basic idea. The benefit of this approach is that it doesn't require daily maintenance for this to work as long as the submodule is tracking the branch. Of course, this could bring in compiler errors from breaking changes in the platform layer.
There's not perfect solution for this. This is just one way that would work and have low overhead for all involved.
Edited by David Owens II
on
Personally, I think the submodules option would probably be the way to go if it weren't for the nasty directory structure that it requires. I'm not sure how much of an impediment that would end up being :/
If people generally think that having the code look like what David posted is not going to bother anyone, then submodules at least seem like they would simplify the process. If the crazy directory structure is going to be a PITA, then maybe not.
- Casey
If people generally think that having the code look like what David posted is not going to bother anyone, then submodules at least seem like they would simplify the process. If the crazy directory structure is going to be a PITA, then maybe not.
- Casey
[strike]Submodules will get quite messy over time, IIRC.
Why not just have two organizations? If you're hell bent on using ONLY the GitHub for Windows client, and not the command line, you're going to be bound by what GitHub can do.
If you use GitHub to host your git repo(s), and you use the command line tools to manage your repos, you can do what you're looking to do. You will have the full feature set of git available to you, not just what GitHub provides.[/strike]
nvm. an assumption i had made was wrong.
Why not just have two organizations? If you're hell bent on using ONLY the GitHub for Windows client, and not the command line, you're going to be bound by what GitHub can do.
If you use GitHub to host your git repo(s), and you use the command line tools to manage your repos, you can do what you're looking to do. You will have the full feature set of git available to you, not just what GitHub provides.[/strike]
nvm. an assumption i had made was wrong.
Edited by Jeremiah Johnson
on
I had learned about submodules from this article: http://bit.ly/1JtyHqA. If we are to stick with GitHub, I say give David Owens suggestion a shot. All the other options I've explored have a steep learning curve and filled with terminological fuckery.
I don't see the value of submodules, except that they would allow public repositories to reference Casey's repository without breaking the code license. It's almost easier to just write "unpack handmade_hero_day_142_source.zip here" in your README (it would even be VCS agnostic). Submodules only work as long as you can use Casey's files unmodified.
Git's strength lies in forking, branching and merging, but this approach requires all repositories to be centrally managed and owned by Casey.
Git's strength lies in forking, branching and merging, but this approach requires all repositories to be centrally managed and owned by Casey.
So, the next question would be, should we just ditch GitHub? If it sucks, it sucks. If we could use a different system that would work better, maybe we should?
I'll be honest, it's really pathetic that it can't trivially do this setup. It's like source code control 101.
- Casey
I'll be honest, it's really pathetic that it can't trivially do this setup. It's like source code control 101.
- Casey
So, another thing I am thinking: maybe we just don't do the community cpp repository at all. Maybe there is just my cpp repository, and then everyone who wants to forks it, and if some of those forks become prominent, the maintainers add people on with push rights.
There would still be separate repositories for the various language ports.
- Casey
There would still be separate repositories for the various language ports.
- Casey
cmuratori
I'll be honest, it's really pathetic that it can't trivially do this setup. It's like source code control 101.
To be fair, your ask isn't trivial. You want an ACL'd remote file share that works across platforms and needs to support versioning. There are few products that even come close to supporting that type of workflow and do it well.
Your last suggestion is what we essentially have today. People have their platform repos and we can clone them today. The only difference would be that we could potentially store them under the Handmade Hero organization instead.
Well, but it would allow people to have the full source code in their repository and not worry about it, which was the primary reason for having a private repository setup. The community cpp repository was a "nice to have" but it's looking to me like not something GitHub can do.
- Casey
- Casey
Yeah, the private fork under the Handmade Hero org is the biggest difference. That's still nice to have.
Yeah, okay. This should stay primitive if the software we're using to handle the code base in any significant way makes for an unpleasant experience.
What the viewers (primarily) want is a single code base that Casey updates over time so they can follow along with little friction. GitHub would solve that. I'm also into the idea of people forking individually, and then letting the interesting or popular ones grow organically.
What the viewers (primarily) want is a single code base that Casey updates over time so they can follow along with little friction. GitHub would solve that. I'm also into the idea of people forking individually, and then letting the interesting or popular ones grow organically.
OK, then for right now, let's forge ahead with just my repo being the CPP repo, then, and not try to solve the community thing officially.
But, there is no reason David et al can't also experiment with the submodule method, since he has admin rights and can make repositories, etc. So if people want to play with making submodules work, and people find that it's pleasant and good, then that can just become an official thing at that point...
- Casey
But, there is no reason David et al can't also experiment with the submodule method, since he has admin rights and can make repositories, etc. So if people want to play with making submodules work, and people find that it's pleasant and good, then that can just become an official thing at that point...
- Casey
It's up on Github now, but I don't Casey has done the work to add people yet.