On 6/5/2014 01:51, j. van den hoff wrote:
what _is_ missing is the GitHub layer
I wish to do without that layer. I like Fossil the way it is: simple to
use, yet powerful. I like being able to host my Fossil repo on my own
server.
Perhaps you're getting hung up on the fact that I described it as
similar in spirit to a Git pull request.
What it *really* is is a request for an uber-patch mechanism.
Another way to think of it is an external form of "fossil stash", with
the ability to reintegrate the private fork with the main repo when the
outside contributor is finished with their little side project.
The only reason we need it is that we don't want to give out Develop
privs to everyone who wants to contribute a patch or two, and the
alternative (fossil diff) is lossy.
fossil should keep clear of the rather obvious flaws
the git community sells as features
Agreed. That's why my proposal doesn't look anything like a Github pull
request. It doesn't require that you "Fork Me On FossilHub", it doesn't
require a formal connection between two repositories, it doesn't require
the contributor to make their repo public, etc.
I don't see that I've added anything complex to the Fossil file format.
It adds:
1. A starting point attribute: "This Fossil repo's initial commit has
hash b49b9b65cb3e3dd3d0970949b5f72e95e7478d84, so if you apply me to
another repo that contains a version with that ID, it forks off from
that version." This shouldn't be more complex than a new single-row table.
2. The ability to intelligently extract a subset of a repo, which I
expect amounts to a CREATE DATABASE call to SQLite followed by a single
clever SELECT statement to copy the changeset into the new DB.
3. The ability to apply that subset to another Fossil repo, using the
starting point version ID as the patch base. I'm thinking of ATTACH
DATABASE, followed by some data copying from one DB to another, followed
by a merge attempt.
4. A few commands to manage all this: fossil submit, fossil apply, plus
extensions to fossil commit and fossil revert to understand temporary forks.
I realize implementing all this will take a fair bit of work. When I
describe it as simple, I mean that I don't see that it changes a lot
about how Fossil works internally.
I also don't expect this to make the user's life any more complicated.
In the end, it should be scarcely more difficult to use than "fossil
diff" + patch, but will give a lot of new power.
The temporary fork concept isn't really new. We already have forks, and
we already have the stash. Once you commit a temporary fork, it will be
an indelible part of the repo, just as if it had been committed and
autosync'd.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
