By the way, the sources are up on http://crna.cc/ now.
However, it's certainly possible, but as 'mparlane says, it would be a lot of (difficult) work.
<_Christina_> no github, i dont like revision control
However, Git (and any other DVCS) does the bookkeeping and keeps you from missing that one small detail at 4AM.
Also, it's much faster to git-commit than to copy 150MB of sources by hand; mostly because Git avoids work where sensible. Ditto for git-diff.
I myself have seen (and had the mispleasure of fixing) many tangled git history trees.
In all cases, you have to be responsible, which neither influences or is influenced by your choice of revision control.
I will get hated for what I've just said.
Are you just not that interested in contributions from the public? If so, I think it's possible you're greatly underestimating community interest in the project.
Setup? git init; git add . (if no unwanted binary in the tree) Something interesting has been done? git commit -am "rock more" New source file? git add file; git commit -m "new foobar module"
What value does it bring? Great revert capability, bisecting bugs, and so over. I agree most of the time I don't need it, but well, when I do it is handy. It is like being insured.
Then again, I don't think many people will take you or your project seriously after this, either. Many of us went past folders and tarballs for version control back in 1992, and personally, there's no way I'm going to touch an OS Kernel that is distributed in a zip file. That is not how you do open source -- for what it's worth, you may want to keep your tarballs to yourself: that'd serve the same practical purpose.
I don't expect that any of the people saying "you should use github to get contributors" actually have the wherewithal to contribute.
Moreover, while I disagree with her stance about SCM, I find it incredibly bikeshed-y that people are talking about that instead of about the technical details of how such a thing is implemented.
Don't any of you have questions or comments about this other than cheerleading, or a bikeshed about SCM? I posted some similar projects that have taken different approaches.
Okay.
Any chance we could get a glimpse of this booting? Maybe a YouTube video?
Is it easy to do static linking? I'm quite happy without shared libraries. And I don't mind being hated for saying so.
Such as typing "git init"?
For a one person project, git is unneeded overhead.
> For a one person project, git is unneeded overhead.
You've never heard of git bisect?
Do you think there is a chance it will be useful to others, and that they might contribute back patches that you will find useful? If so, it makes sense to make that as easy as possible. Otherwise you are sabotaging your own goals and putting unnecessary barriers between you and your potential contributors.
Sign-up aside, all you would need to do is type "git init" and then set up a one-line script that will do a commit and push it to github. If you want to be nice, you'll type in a message. Voila, you now have a way to:
* let people subscribe to your project
* automatically maintain and announce your changelog
* let them fork your project, make changes, and send those changes back to you as a diff which you can comment on online
* merge those changes back into your tree with a single click / command
Additionally, while you might be confident managing a single code tree, there are things that filesystems don't do well, like branching. I find being able to try new things and setting them aside for a while is invaluable. It lets me be bold and work on whatever I fancy, without having to worry about what I was doing before.
Don't think of git as revision control, think of it as a little robot that lets you do controlled operations on code trees, like you can with files.
If you're going to fork someone else's project, either rename, or call your github fork a mirror (and treat it purely like one).
The author may not be interested in managing contributions or using source control, that is their prerogative, but as long as the license permits it if people want to work on the source code and collaborate with others, it is completely fine (and encouraged) for them to fork it
This is basic OSS politeness and the cultural norm. Only recently has Github trained people to think its OK to take someone else's work, keep the name, and siphon off interest/contributors.
If you want to fork, then do so. Treat it like the new project it is, instead of trading off the name and efforts of someone else, and operating independently of their development standards and norms.
Or, be polite, and accept that the choice of VCS is a stupid reason to fork someone else's project.
(I don't remember what he exactly said, but it's something to this effect): I hate revision control, that's why I created git.