On 03/21/2012 02:04 PM, Mathias Gaunard wrote:
On 21/03/12 13:22, Thomas Heller wrote:
To be honest I don't know what's the right way to deal with published forks.
Right, and isn't this exactly what is advocated here as one of the big advantages of git in specific and DCVS's in general?
Is it? I didn't follow all discussions, I wasn't aware the ability to publish forks was advocated as "one of the big advantages of Git".
To me, it's certainly way past the big advantages.
That is what I understood, yes. The first big advantage i took out of the discussion was the ability to do local commits. Where git has the advantage over mercurial (maybe not anymore, but doesn't really matter) that you can polish up those local commits before you push them to some public repository. This public repository might not be the same as the official upstream repository, which brings me to the next big advantage: When different people work on a project, they might need to share their current work. This will be done by somehow notifying the others to pull from their repository, right? of course, in order to ensure minimal disruption of your peer, you want him to pull a version which is compatible to what he published already. Which is what i tried, and what was confirmed by Mathias to not work properly. Additionally, of course, when different forks, with different features lie around the interwebs, the user will want to choose the repository which is maintained best. Thus a "private" public fork may suddenly become public and the havok is complete. Maybe this is a complete misunderstanding of the workflows, but that is what I personally took out of these discussions.