On Wed, Jun 25, 2008 at 12:36:03AM -0000, David Jeske wrote: > The purpose of this mechanism is to host a distributed source > repository in a world where most most developer contributors are > behind firewalls and do not have access to, or do not want to > configure a unix server, ftp, or ssh to possibly contribute to a > project. > design assumptions: > > - all developers are firewalled and can not be "pulled" from directly. > - there can be one or more well-connected servers which all users can access. > - .. but which they cannot have ssh, ftp, or other dangerous access to > - .. and whose protocol should be layered on http(s) > - there is a shared namespace for branches, and tags > - .. users are not-trusted to change the branches or tags of other users Up to here, you can do this all with repo.or.cz, and/or github; you just give each developer their own repository, which they are allowed to push to, and no once else. Within their own repository they can make changes to their branches, so that all works just fine. > (a) safely "share" every DAG, branch, and tag data in their > repository to a well-connected server, into an established > namespace, while only changing branches and tags in their > namespace. This will allow all users to see the changes of other > users, without needing direct access to their trees (which are > inaccessible behind firewalls). [1] Right, so thats github and/or git.or.cz. Each user gets his/her own > repository, but thats a very minor change. Not a big deal. > (b) fetch selected DAG, branch, and tag data of others to their tree, to see > the changes of others (whether merged with head or not) while disconnected or > remote. This is also easy; you just establish remote tracking branches. I have a single shell scripted command, git-get-all, which pulls from all of the repositories I am interested in into various remote tracking branches so while I am disconnected, I can see what other folks have done on their trees. > (c) grant and enforce permission for certain users to submit _merges > only_ onto certain sub-portions of the "well-named branches" This is the wierd one. *** Why ***? There is nothing magical about merges; all a merge is a commit that contains more than one parent. You can put anything into a merge, and in theory the result of a merge could have nothing to do with either parent. It would be a very perverse merge, but it's certainly possible. So what's the point of trying to enforce rules about "merges only"? - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
