{"thread":{"id":"43836","subject":"policy and mechanism for less-connected clients","startedAt":"2016-08-14T00:43:10Z","lastAt":"2016-08-14T00:43:10Z","messageCount":1,"participants":["David Jeske"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"299231","messageId":"willow-jeske-01l67VSgFEDjChUQ","threadId":"43836","inReplyTo":null,"subject":"policy and mechanism for less-connected clients","fromName":"David Jeske","fromEmail":"jeske@willowmail.com","sentAt":null,"receivedAt":"2016-08-14T00:43:10Z","isPatch":false,"sender":{"key":"jeske@willowmail.com","avatar":null},"body":"I'd like to hear feedback and ideas about a different mechanism than is being\nused with git-pull or git-push.\n\nThe purpose of this mechanism is to host a distributed source repository in a\nworld where most most developer contributors are behind firewalls and do not\nhave access to, or do not want to configure a unix server, ftp, or ssh to\npossibly contribute to a project. The model of allowing less-authoritative\ndevelopers to make their changes available for more-authoritative users to pull\nis accepted as superior. However, no users are assumed to be authoritative over\neach-other, or an entire tree, and many users should have authority only to\nsupply new deltas to their own branches. The ability to handle emailed patches\nis an asset, but is deemed too manual for this need.\n\nI believe git's design is strong; that many of the mechanisms are already\nbuilt; that new mechanisms to build this can be simple; and that with such\nmechanisms, many more developers would have access to git's decentralized\ndevelopment style. Further, it would address drawbacks in today's git relative\nto public central version control systems, making this system closer to a 'best\nof both worlds'.\n\ndesign assumptions:\n\n- all developers are firewalled and can not be \"pulled\" from directly.\n- there can be one or more well-connected servers which all users can access.\n- .. but which they cannot have ssh, ftp, or other dangerous access to\n- .. and whose protocol should be layered on http(s)\n- there is a shared namespace for branches, and tags\n- .. users are not-trusted to change the branches or tags of other users\n- .. only certain users are trusted to change the shared origin branches\n- .. also allow directory ACLS on shared branch commits\n- all their DAGs should be in a single repository for space efficiency\n- users generally want to follow well-named branches\n- .. will be free to follow any branch, and pull changes from any branch\n\nI would like to make it easy for users to:\n\n(a) safely \"share\" every DAG, branch, and tag data in their repository to a\nwell-connected server, into an established namespace, while only changing\nbranches and tags in their namespace. This will allow all users to see the\nchanges of other users, without needing direct access to their trees (which are\ninaccessible behind firewalls). [1]\n\n(b) fetch selected DAG, branch, and tag data of others to their tree, to see\nthe changes of others (whether merged with head or not) while disconnected or\nremote.\n\n(c) grant and enforce permission for certain users to submit _merges only_ onto\ncertain sub-portions of the \"well-named branches\"\n\nThere are many many benefits of git's mechanisms for this topology, and I\nexpect you know them so I'll skip them. I see the following challenges from the\ncurrent git implementation. Please tell me where I'm mistaken.. this is all\nAFAIK, some from tests, some from docs.\n\n(1) A server will need to support the required permissions and isolation\nenforcement. Namely, permissions for portions of the branch/tag namespace,\nassurance that DAGs are valid, and directory permissions.\n\n(2) a \"share\" client command will need to be implemented which transmits-up\nlocal changes to only my DAGs, branches, and tags without affecting the shared\norigin namespace pointers on the server. It will share all these changes\nregardless of what the user's \"active\" branch is. Local branches might be\nmapped to a branch on the server such as origin/users/(username)/(branchname).\nBranches which are supposed to stay local might be named \"local/branch\", and be\nignored by the \"share\". [1]\n\n(3) a mechanism for controlling permissions (possibly based on checking out and\nediting a special subtree, ala cvs)\n\n(4) A mechanism to be sure \"share\" does not cause users who have permission to\ninadvertently move the origin/master branch pointer, even if they are working\non their local master branch. For example, their changes would be named by\norigin/users/(username)/master. This is necessary because \"share\"  is the only\nway for the firewalled user to make their changes available to others. As a\nresult, it is imperative that this be separate from a decision to promote their\nchanges onto the shared origin branch. Currently git-push implies both of these\ntogether. git-share would be to git-push what git-fetch is git-pull. git-push\nwould continue to be used to tell the system you wish to promote your change to\norigin/master. [2]\n\n\n[1] - \"share\" permissions can be considered two ways. In the strictly client\nserver model, the server will only allow the client to change branch pointers\nthat it owns in the namespace. However, if clients establish their own PGP-keys\nor other hash-identity keys with the server, then branch changes may be signed\nby clients, and propagate between clients in any direction and order, until\nthey fully propagate. It's not clear if this additional complexity is worth it.\n\n[2] - it might be reasonable to build a mechanism to allow a local \"intent to\npromote\" preceed a git-share, in which case git-share could safetly\nfast-forward the head. However, it's unclear what benefit this has over\ngit-fetch.\n"}]}