Yup! Looks good. (I read the whole thread, but this seemed like best message to which to reply. I think Jungle-Boogie's comment about being able to accept directly from the UI for things like text updates would be great... but it could be added later.)
Will need a bit of documentation to help people understand the workflow. The user might have made some changes and committed to their local trunk before they realize that they have a contribution to make, so a command to move all changes in the local repo that are different from the remote repo into a new branch would help with that: `fossil delta`? and then `fossil contribute-delta` (which has contribute as a prefix and is therefore better than push-delta because that has an existing (related) command as prefix) would be a natural way to contribute it to the repo. (The delta might be just for the branch they are on... e.g. there is a normal branch that one of the committers is working on called foo, and the user might have made changes to foo and trunk... so they should do 2 deltas - one for the foo branch and one for the trunk.) I think this would significantly address the "no pull-request" complaint that seems to be the leading excuse - other than "it's not GIT". ../Dave On 15 June 2018 at 13:35, Richard Hipp <d...@sqlite.org> wrote: > On 6/15/18, David Mason <dma...@ryerson.ca> wrote: > > I heartily agree with this... A flag to allow a person (including > > Anonymous) to make a commit that would automatically go into a new branch > > like "Patch-1" (each one incrementing the branch number) is (a) better > than > > emailed patches, and (b) better than pull requests. Primarily because it > > puts it into Fossil so you can use all your standard workflows. > > > > The "Patch-?" branches should not be automatically synced, and if you do > a > > sync with some special flag, it should offer each of the existing patch > > branches and allow you to agree to sync it, or not. Then there needs to > be > > a way to delete the patch branches (whether included into the trunk or > not) > > An alternative design sketch: > > (1) Anonymous clones repo CoolApp > > (2) Anonymous makes changes to CoolApp and checks those changes into a > branch named "anon-patch" on her private clone. Repeat this step as > necessary to get anon-patch working. > > (3) Anonymous runs the command "fossil pullrequest anon-patch" > > (4) The pullrequest command creates a "bundle" out of the "anon-patch" > branch and then transmits that bundle back to the server from which > the clone originated. > > (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. > > Additional notes: > > Prior to step (3), Fossil might require Anonymous to provide contact > information so that developers can get in touch in case there are > questions or requests for clarification. Anonymous might also be > asked to sign a contributors agreement to be included in the bundle > (as an entry in the bconfig table). > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
