Richard Hipp: > (5) The server accepts the bundle and parks it in a separate holding > table, but does not merge it or otherwise make it available to average > passers by. The server then sends email notifications to developers > with appropriate privileges to let them know that a pull request has > arrived.
> (6) Developers who receive notification of the pull request can run a > command that pulls down the bundle and applies it as a private branch > on their own personal clones of the repo. Developers can then either > approve of the pull request by publishing it (marking it non-private) > and pushing it back to the server. Or they can reject the pull request > which erases it from their clone. They might also cause the pull > request to be erased from the holding table on the server. From my experience with GitHub pull requests, it seems that they are visible to the public and open for review and comments even before they are reviewed and accepted by the upstream project, and anybody interested can take the submitted code to their own clone. It has a less "open" character if core developers need to become active to make pull requests visible to the public, more so if they can delete submissions without anybody from outside of their team ever noticing. If bundles were reworked to be "sets of patches", they could me made visible to the public more easily, before reaching the main repository store. And there would be the already mentioned greater flexibility with meta-data (allowing the receiver to decide about the merge base, the check-in comments, as well as the branch name and other tags). --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
