On 22/03/2012 10:43, Thomas Heller wrote:
On 03/22/2012 11:32 AM, Martin Geisler wrote: ...
If you publish a repository on GitHub and tell me about then I might look at the commits there and give you feedback. If I'm not basing any work on the changes, then it's no problem if you later destroy the commits and even delete the repository. Right, the *second* i hit the "fork" button on github, everyone sees my new repository.
right. The usual way to use (any) DVCS is that this publicly available fork repository (i.e. github) is considered shared work, meaning you only append your work there (no rewriting history). If you want to use DVCS in distributed manner, your commits would go first to your local repository (i.e. filesystem on your local machine) where you can tweak them to your heart's content before pushing them to shared repository (after which point these commits are shared and thus should not be changed any more). Since everyone else (with right permissions) does the same, it's very easy to keep track of other's work because you will frequently rebase your local repository from the public one, with someone elses work appended to it. This trigers automatic merging of changes in your repository which you have not shared yet (on top of current head of shared repository, as copied to your repository). Most of the time this merging process is fast and totaly transparent. And when it is not, getting out of trouble is not really that difficult - normally just manually fix files when git asks you to do so, or at worst you do "git rebase --abort" and try again. B.