Hacker News Reader

If it's a personal project, it's largely a matter of taste, I think. I did tarball-upload style myself before.

I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests).

Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.

> if someone finds a bug, he can e-mail me a patch or even notify me about it.

A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes."

Users can run "blame" to find out which commit touched what line of any file.

Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage.

> then I upload tar.xz's of the project for each "release".

All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag:

  $ git tag frumly-widgets-2.3
  $ git push --tags

Done! Users can now download frumly-widgets-2.3.tar.gz straight out of the web front end.

> If I was going to use a public repository, I think I'd end up using CVS.

Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.

You politely and clearly explained why you're unconvinced a repo would benefit you. You got a couple replies pointing out some advantages, which maybe you hadn't considered or at least some other people might not have known about.

Result? Nice discussion. Opportunity for folks to learn something new.

And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.