Which is what Git does: every commit actually is a directory/file tree and a small note a.k.a. `commit message'. You could re-create the effect by hand, by placing `.commit' file in root of the multiple directories you speak of.
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 can understand and sympathize with "no github, I don't like github" or "I don't like git", or "I don't like social networking" or "I don't like horny virgin hacker boys cyber stalking my every edit" but what the hell?
I'm the only maintainer of this project. I find revision control redundant, since it takes extra steps to set up and use while being of very little value. I'm reasonably good at maintaining my tree without needing any fancy revision control systems (git/svn/whatever).
It might provide little direct value to your development process, but the real question is, why are you posting this project on the internet?
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.
This is Hacker News; we try to stay civil, so I don't think many people are going to "hate" you for not using (understanding?) version control.
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'm going to take christina_b seriously because this is a seriously complex problem, and it's impressive that she's gotten so far with it.
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.
That makes sense if it's just you, but you must be losing a lot of potential contributors by not being on Github, let alone not using any version control.
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.
I find I'm always happy I used hg when I get the inevitable sneaky bug in unrelated code. Being able to easily step back through history and run my tests at every step to see where they fail has been very useful many times.
I use hg locally on personal projects also. I very rarely actually need to go back to a prior version, but it gives me more confidence to try different things, knowing I can easily revert to a working version.
I hate you! More seriously git is super easy to begin to use, and even more so for small projects and / or projects with a small number of contributors.
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.
To elaborate, it's rude to take someone else's project, and under the same name, publish it elsewhere. This has been a rule of open-source for a very long time.
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).
This has most certainly not been the rule of open source, its almost the opposite of the 'rules' of open source.
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
Putting a version of an open source project into version control is not a fork, you could argue the same way that distributions are forking all software because they put them in packages. To fork you have to write code.
Putting it into public version control and accepting patches is a fork -- name it something new. If it's just a mirror, then call it that, and don't accept patches.
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.
<_Christina_> no github, i dont like revision control