> 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.
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:
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.