On Mon, Apr 6, 2015 at 10:05 AM, James Moger <james.mo...@gmail.com> wrote:
> I thought forks were blocked by the push in git. What scenario can lead to >> dual heads in git? >> > > By default non-fast-forward pushes (fork in Fossil terms) are blocked. > This is what I thought. So what technical obstacles are there preventing fossil from adopting this behavior? One idea: all blobs could be sync'd but blobs would need to be blessed before becoming part of the official fossil record. Various mechanisms might exist for such blessing. The anti-fork mechanism: before a node is blessed it would need to prove that the node it was derived from had no children unless the branch name was different. Anyone trying to push a non-blessed blob would get a big fat warning and the onus would be on them to resolve at their end before trying to sync again. > > If you have permission to force a non-fast-forward push then you can > replace/overwrite the current branch "tip/HEAD" pointer. This most likely > means the previous branch "tip/HEAD" pointer is de-referenced (i.e. no > longer accessible through a named branch or tag). These original tip/HEAD > commits are still in the repository but eventually they will be > garbage-collected. > > There is no *direct* analog of the Fossil fork feature, although you could > crudely simulate one, I suppose, with server-side refs. > > -J > > > _______________________________________________ > 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
