As far as I can tell, Fossil offers two ways to allow outsiders to
submit changes to an open source software project:
1. Give them Develop privs
2. Ask them to "fossil diff" and mail you a patch file
In my open source project, I only give repo checkin privileges to
contributors who have submitted a few quality patches first, at least.
Most contributors submit only a patch or two and then go away, never to
be heard from again, their itch scratched.
The thing is, a unified diff cannot express all the information Fossil
knows: file moves/renames/deletions, commit comments, the difference
between a changeset and a monolithic patch, the point in the revision
history the diff was made against...
Git solves this problem with the pull request. Since it is one Git
repository talking to another, no information is lost. I agree that Git
is far more complex than necessary for most projects, but to the extent
that Fossil tries to be Github-in-a-box, it would be nice to have
something more analogous to a pull request than "fossil diff".
I think you could do it with a variant of the Fossil repo file format.
It would be the same as the current format, with only two minor differences.
First, it would be a subset of the contributor's repository, not a full
clone, containing just the range of changes the contributor made.
Second, it should have an attribute that tells where this repo fragment
started from, relative to the central repo.
Because it is still the Fossil DB format, it would record all the
changes the outsider made, with no information loss.
The workflow from the contributor's side would be:
$ fossil clone http://blabla ; fossil open, etc
...hack, hack, hack...
$ fossil submit -f contrib.fossil
...send contrib.fossil to the project's mailing list; OR:
$ fossil submit
...local Fossil attempts to create a new ticket on central repo
I am assuming that "fossil submit" wouldn't need to be told the starting
point of the submission since the outsider's first "ci" will create a
fork when autosync fails. True? If Fossil can't reliably know where to
start, it could have a -r option to make the starting point explicit.
The workflow from the project insider's point of view would be:
$ fossil apply contrib.fossil
Temporarily applied change set [8769d876b8]
$ fossil ui & # examine the changeset
$ make && make test # does the changeset break anything?
$ fossil ci -r 8769d876b8 # accept the changeset...
$ fossil reject 8769d876b8 # ...or reject it
The workflow for accepting a changeset submitted as a new ticket would
be similar, only with buttons walking the insider through the process of
examining and accepting or rejecting the changeset. The insider would
have to drop to the command line and say something like "fossil co
8769d876b8" to do the "make && make test" steps.
After the contribution is applied to the central repo, when the
contributor says "fossil up", their Fossil should recognize the hashes
it generated and be able to figure out what happened.
Aside from the ability to mediate an untrusted outside contribution,
this feature would also solve the "monolithic patch" problem, where the
patch mixes several steps together. With the current unified diff
workflow, I either have to be an ogre and demand that my unpaid
contributor resubmit it as a pile-o-patches or spend time disentangling
the steps and checking them in individually.
I chose to overload the "ci" command here because I want it to work the
same way. If the contributed changeset merges cleanly with the branch
the contributor did his work against, it should do just that. If not,
it should offer to create a fork, just like a normal "ci".
If the contribution merges cleanly, I'd expect to see a bulge in the
repo history under "fossil ui", like a side track on a railroad: a
temporary divergence that merges back in with the main line of
development. I want to be able to look back over the graphical revision
history and instantly pick out the occasional outside contribution
against the background of steady work on the main development line.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
