Hey all,
GitHub setup is proceeding apace, although honestly, GitHub is a bit toyish in my opinion, but that is probably just my grumpiness :) As a result, it can't quite set up things the way I would prefer they were set up, and I would like some suggestions on what would be most useful to people in lieu of what I would do if GitHub was actually an industrial-strength tool.
Current set-up. I have done the work of making a GitHub repository which has all of the days of Handmade Hero as commits, labeled with the title of the video to which they correspond. I have also tested granting access to a language port maintainer to set up a separate repository, and that works fine, too.
What I would have liked to do, but can't. What I would have liked to do was keep the main repository such that only I have push rights, and I would just push to it every night after the episode is done. I would then create a fork of this repository that was the community's version of the code, and I would grant admin access to a number of Handmade Hero community members so that they can organize push rights for people doing ports to other platforms, etc.
This way I would never pull, so I don't need to be aware of any community work that is going on to make good merge decisions, etc. But the community can collaborate on a forked tree where they can build in the standard Mac, Linux, etc. ports and merge with my changes easily. Seems like the obvious way to set this up.
Unfortunately, GitHub can't do this. GitHub doesn't allow an organization (ie., HandmadeHero) to own both the original repository and the fork. Any Git fork on GitHub has to be owned by a different organization or individual from the original. This is kind of absurd, but I contacted support and they assured me it really was a limitation of GitHub.
What should we do? So, this limitation will not cause problems for people who want to maintain their own forks - that is fine. It's only a problem for having an official community fork with a team of admins, etc.
My current thinking is that the best strategy might be to just forgo the forking, and make merges happen manually. Ie., I will just maintain a repository called "casey" under Handmade Hero, which is my branch, and everyone has pull rights but nobody has push rights except for me. Then, there would be a community repository called "cpp" for the C/C++ port where people just manually merge in my changes as they wish.
But I don't know if that is the most logical thing to do. I am open to suggestions.
One suggestion might be that GitHub sucks (obviously true) and we should use something else. Another might be that it is not important to have a community repository, and that everyone will just make their own forks and then invite people onto the forks. I don't know. How that works out when you want to make something that is "the community version of Handmade Hero that has both the Mac OS X code and the Linux code" I don't know, but maybe it's fine.
- Casey
GitHub setup is proceeding apace, although honestly, GitHub is a bit toyish in my opinion, but that is probably just my grumpiness :) As a result, it can't quite set up things the way I would prefer they were set up, and I would like some suggestions on what would be most useful to people in lieu of what I would do if GitHub was actually an industrial-strength tool.
Current set-up. I have done the work of making a GitHub repository which has all of the days of Handmade Hero as commits, labeled with the title of the video to which they correspond. I have also tested granting access to a language port maintainer to set up a separate repository, and that works fine, too.
What I would have liked to do, but can't. What I would have liked to do was keep the main repository such that only I have push rights, and I would just push to it every night after the episode is done. I would then create a fork of this repository that was the community's version of the code, and I would grant admin access to a number of Handmade Hero community members so that they can organize push rights for people doing ports to other platforms, etc.
This way I would never pull, so I don't need to be aware of any community work that is going on to make good merge decisions, etc. But the community can collaborate on a forked tree where they can build in the standard Mac, Linux, etc. ports and merge with my changes easily. Seems like the obvious way to set this up.
Unfortunately, GitHub can't do this. GitHub doesn't allow an organization (ie., HandmadeHero) to own both the original repository and the fork. Any Git fork on GitHub has to be owned by a different organization or individual from the original. This is kind of absurd, but I contacted support and they assured me it really was a limitation of GitHub.
What should we do? So, this limitation will not cause problems for people who want to maintain their own forks - that is fine. It's only a problem for having an official community fork with a team of admins, etc.
My current thinking is that the best strategy might be to just forgo the forking, and make merges happen manually. Ie., I will just maintain a repository called "casey" under Handmade Hero, which is my branch, and everyone has pull rights but nobody has push rights except for me. Then, there would be a community repository called "cpp" for the C/C++ port where people just manually merge in my changes as they wish.
But I don't know if that is the most logical thing to do. I am open to suggestions.
One suggestion might be that GitHub sucks (obviously true) and we should use something else. Another might be that it is not important to have a community repository, and that everyone will just make their own forks and then invite people onto the forks. I don't know. How that works out when you want to make something that is "the community version of Handmade Hero that has both the Mac OS X code and the Linux code" I don't know, but maybe it's fine.
- Casey
I sent a more detailed email about this, but I think you want top-level repos for your setup instead of forks. These repos can have different maintainers and can use git submodules to point to the latest working version (e.g. no breaking changes to the platform layer) of Handmade Hero.
The submodules idea you proposed sounds like the best work-around so far. I don't have any experience with that, so I'd have to look into it, but it's the best option I've heard...
- Casey
- Casey
Certainly, it's all about finding the most pragmatic workarounds. =)
I think it might also possible to symlink other repositories into your own, but it seems it's only a superficial thing.
Users who want to clone via your repo have to use the --recursive switch to git. (awkward)
Example of a site that uses linking is:
https://github.com/getpelican/pelican-themes
Users who want to clone via your repo have to use the --recursive switch to git. (awkward)
Example of a site that uses linking is:
https://github.com/getpelican/pelican-themes
That is what the submodules are, essentially symlinks.
You either do this:
git clone --recursive <path/to/repo.git>
or
git submodule update
In your already cloned repo.
You either do this:
git clone --recursive <path/to/repo.git>
or
git submodule update
In your already cloned repo.
You can use separate repos for this. I don't think that one needs to be a fork.
You should be able to use multiple remotes to do this.
http://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
When you clone a repo, it setups a remote with the default name origin pointing at your github repo.
You can manually add another remote using
git remote add community github_url_here
Then you can
and update both repos.
You should be able to use multiple remotes to do this.
http://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
When you clone a repo, it setups a remote with the default name origin pointing at your github repo.
You can manually add another remote using
git remote add community github_url_here
Then you can
1 2 | git push origin master git push community master |
and update both repos.
That's going to cause Casey to have to sync the community one as well otherwise it will error when trying to push because it will contain changes.
Also, this adds in the ability for the community to inadvertently modify Casey's version.
Also, this adds in the ability for the community to inadvertently modify Casey's version.
Or he could push to a different branch like
or something like that. Then the community maintainers can handle the merges how ever they want. But in that case it seems like the work flow may be better like this.
Casey pushes to one repo, and that's all he cares about. No overhead for Casey.
Community managers clone the community repo, and add Caseys repo as another origin.
Community managers pull in the nightly updates from Caseys repo and merge as needed and push back to the community repo. Everyone can fork the community repo and have a nice history of changes coming in.
1 | git push community from_casey |
Casey pushes to one repo, and that's all he cares about. No overhead for Casey.
Community managers clone the community repo, and add Caseys repo as another origin.
Community managers pull in the nightly updates from Caseys repo and merge as needed and push back to the community repo. Everyone can fork the community repo and have a nice history of changes coming in.
[EDIT] Everyone beat me to it! :pinch:
Anders Kaare's twitter reply is probably a better bet than submodules (much internet whining has been done about git submodules):
https://twitter.com/sqaxomonophonen/status/615588052614926336
Say you have github.com/hmh/handmadehero
So make github.com/hmh/handmadehero_community but don't push to it yet, and don't tell it to add default files. You want to take a local clone of the master Casey repo and redirect it to the community repo. This won't be an ordained Fork in the Land of Github, in that their database doesn't store a special pointer from one to the other, but it's effectively a fork.
[pre]
git clone git://github.com/hmh/handmadehero.git
mv handmadehero handmadehero_community
cd handmadehero_community
git remote set-url origin git://github.com/hmh/handmadehero_community
git remote add origin-casey git://github.com/hmh/handmadehero
[/pre]
Now someone who has cloned hmh/handmadehero_community can also fetch and merge changes from hmh/handmadehero, and subsequently push those changes to hmh/handmadehero_community if they are on the contributor list for that repo.
[pre]
cd handmadehero_community
git pull origin master
git pull origin-casey master
# clean up the mess...
git push origin master
[/pre]
Anders Kaare's twitter reply is probably a better bet than submodules (much internet whining has been done about git submodules):
https://twitter.com/sqaxomonophonen/status/615588052614926336
Say you have github.com/hmh/handmadehero
So make github.com/hmh/handmadehero_community but don't push to it yet, and don't tell it to add default files. You want to take a local clone of the master Casey repo and redirect it to the community repo. This won't be an ordained Fork in the Land of Github, in that their database doesn't store a special pointer from one to the other, but it's effectively a fork.
[pre]
git clone git://github.com/hmh/handmadehero.git
mv handmadehero handmadehero_community
cd handmadehero_community
git remote set-url origin git://github.com/hmh/handmadehero_community
git remote add origin-casey git://github.com/hmh/handmadehero
[/pre]
Now someone who has cloned hmh/handmadehero_community can also fetch and merge changes from hmh/handmadehero, and subsequently push those changes to hmh/handmadehero_community if they are on the contributor list for that repo.
[pre]
cd handmadehero_community
git pull origin master
git pull origin-casey master
# clean up the mess...
git push origin master
[/pre]
Edited by drjeats
on
How does this make things easier for people who maintain their own forks? These are by all rights, separate projects. Linking to external projects is more appropriate because branching implies these external projects will ultimately be merged into Casey's mainline, when they will not be.
Secondly, expecting "Community Managers" to do nightly merges will disintegrate after a month or so, because volunteers have a habit of disappearing after awhile. It also means someone has to be in charge of coordinating who has commit bits and who doesn't. Which would be Casey.
It sounds like a lot of political overhead for no technical benefit.
Secondly, expecting "Community Managers" to do nightly merges will disintegrate after a month or so, because volunteers have a habit of disappearing after awhile. It also means someone has to be in charge of coordinating who has commit bits and who doesn't. Which would be Casey.
It sounds like a lot of political overhead for no technical benefit.
Yeah, submodules seem to be the way to go. I use nxsy's XCB platform layer and currently symlink the HMH source into xcb_handmade/src/ anyway (from a separate directory to which I unzip it), so I think I can see how submodules will work similarly to that.
However, if I edit one of these symlinked files, its target file obviously changes too. Furthermore, if I then unzip and link a different day's source, I naturally lose my edits. This doesn't / can't happen with git submodules, though, can it, since the sub-repository "has its own history"? Sorry if I'm misunderstanding how they work.
However, if I edit one of these symlinked files, its target file obviously changes too. Furthermore, if I then unzip and link a different day's source, I naturally lose my edits. This doesn't / can't happen with git submodules, though, can it, since the sub-repository "has its own history"? Sorry if I'm misunderstanding how they work.
If you wanted to make edits to the HMH source, you would do the following:
1. Fork the HMHCommunity version
2. Fork the HMH proper version
3. Update the HMHCommunity forked version to point to your own fork
Now you are in charge of keeping your HMH fork up-to-date with Casey, but you can modify that source to your hearts content.
Without the fork for the HMH version, a submodule update will override your changes.
@Allan, yes, nightly merges will simple stop happening.
1. Fork the HMHCommunity version
2. Fork the HMH proper version
3. Update the HMHCommunity forked version to point to your own fork
Now you are in charge of keeping your HMH fork up-to-date with Casey, but you can modify that source to your hearts content.
Without the fork for the HMH version, a submodule update will override your changes.
@Allan, yes, nightly merges will simple stop happening.
Edited by David Owens II
on
Can you elaborate on the submodules idea? Last time I used them (a few years ago) they were very annoying. Are they better now?