Hello list, Long-timer lurker, first-time post.
On Mon Jul 09, 2012 at 12:54:01AM -0500, Nick M. Daly wrote: > On Tue, 3 Jul 2012 18:28:03 +0200, Mathieu Jourdan wrote: > > > https://github.com/NickDaly/plinth > > > > By fork, do you suggest to create one more account then a third Plinth > > repository on github? Isn't it preferable to push to existing > > repositories, avoiding confusion to new contributors? By confusion, I > > mean it's not easy to get a clear picture on what has been done if one > > has to browse multiple repositories for the same piece of software. > > That's how distributed revision control systems work: each copy of a > repository is its own repository. By making forking technically > required, it becomes a social, not technological, issue. Projects as a > whole move forward when multiple forks are rolled up into a parent > branch. Child branches that don't amount to anything are ignored, along > with parent branches that don't accept changes. That's not how all Distributed Version Control Systems (DVCS from here on) _have_ to work, that's just is how github chose to implement their model of a DVCS for "social coding" purposes. Github threw away the single-hub-and-spokes model and replaced it with multiple- hubs-and-spokes. In order to publish even the tiniest single-line patch to a repository, users are required to fork the *entire* project. I agree with Mathieu that this leads to confusion: "where is the primary source for this project??" I have also forked projects and then forgotten to set up the remote back to the original repo and then wondered why "pull" wasn't getting external updates. They could have chosen instead to keep the idea of a single synchronisation repository with multiple branches (named "fork/username/*" perhaps?) and used fine-grained permissions[1] to allow anyone to create a new branch under the "fork/username" namespace, and only those who the project decides could commit above that. The issue tracking system could also be smart and attach issues to commits (which would allow for per-branch issues that migrate easily) If this were the model then the difference between a "code fork" and a "project fork" would be much more obvious than they are on Github. Unfortunately it seems Gitorious went down the same path. Just because DVCS allows some things to be distributed doesn't mean they all should be, but that's the model followed so far. Sorry for pushing this thread further off-topic and not having anything more constructive to add. [1] See http://sitaramc.github.com/gitolite/master-toc.html for how fine-grained permissions can be done. Mark. -- Mark Lawrence
signature.asc
Description: Digital signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
