One partial solution available today is to use http://chiselapp.com. Simply use their "clone repo" feature with regular pull. What is missing is a way to register the "fork" with the original project. It would be cool if it was possible to submit the URL of the forked repo to the parent. The parent can verify that the URL is a real "fork" and not some random URL and then make the forks (with description?) browseable on a "Forks" page.
The final piece of the puzzle would be the mechanism to pull only a single branch from a remote repo. What are the technical challenges with that? Is it enough to query the db for all the nodes on the branch and pull only that data or is there more to it? On Wed, Dec 12, 2012 at 3:27 PM, C. Thomas Stover <[email protected]>wrote: > <blabbing> > I have made some great progress on my continuing quest for fire with > Fossil yesterday and today. In this episode, my juggling of > over-committed time cycled back around to answering questions about > branching and merging in the context of various development models > using Fossil. > > In no way am I ashamed to say this this entire area (not just with > Fossil) can be exceedingly complex, and really can make an old dog > feel incapable of learning new tricks. Chin up, and persevere. For all > the playing around with it is very much worth the headaches. The DVCS > model(s) really are powerful time amplifying tools, of which Fossil > clearly is the least nonsense, most purposeful winner. > </blabbing> > > For example, to experiment with some private changes to an actively > developed codebase within a publicly cloneable Fossil project, one > simply (honoring licenses, etc): > 1. clones it > 2. makes a branch > 3. hacks > 4. occasionally --pull from the official project; and merge with trunk > 5. optionally publicly host this repository > > Now for some questions and observations... > > If the official project maintainers would like to bring in this branch > onto their own Fossil server (either to simply host it, or to attempt a > merge) they can do so with a --pull. However this currently would have > the consequence of the all or nothing (wiki pages, other branches, > tickets) behavior. Even so, having Fossil display and generate diffs so > as to allow the changes of choice to be visualized and read clearly > before being patched into a forked version (official or otherwise) is > still about 1000:1 sanity improvement over emailing diff attachments. > > A project using Fossil may host some code with a F/OSS license of some > kind, but it may or may not have as copyright holders granted the right > to re-host things like wiki pages. So this detail would need to be > considered before hosting a clone of someone else's project. Again some > type of clone/push/pull granularity might be useful to avoid a legal, > courtesy, or outright malicious incident. > > Consider the case of a new user who wants to try out your project. So > they google "your project name". The user unknowingly ends up at the > site of some kid who had no intention infringing on your trademark, but > was instead simply trying to give back their hack, for say - GPL > compliance. (contrived, but you get the point) > > In the case of the Fossil project specifically, what sort of steps > would make it ok to say "hey folks check out fossil hack, it's up on a > cloned repo at url abc". Even if one was in the position of a regular > contributor, they still might want to do something like this as sort of > a "public private branch" in between contribution worthy revisions. > > > -- > C. Thomas Stover > Stover Enterprises, LLC > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
