On Mon, Apr 25, 2011 at 4:58 PM, Richard Hipp <d...@sqlite.org> wrote: > "Leaf" is purely a UI concept. Fossil does not use leaves internally for > anything itself (that I can think of off hand.). Fossil keeps track of > leaves purely so that it can tell the user what the leaves are.
Fossil also issues a "would fork" warning in the even that a user tries to commit against a commit that is no longer a leaf - at least when it knows it is no longer a leaf. (Unless that warning has been removed recently.) > This gets back to the original problem. Everybody has an intuitive idea of > what a "leaf" is. But the concept of "leaf" turns out to too subtle to be > easily captured by intuition. To me, a leaf seems very simple: It is a node where making a commit will not require either branching or forking to complete the commit. Also, I do not consider the presense a merge-child to require creating a branch or fork. As far as a leaf being left open after a merge, that is what I would expect, because it allows me to continue development from that point without any special action. I would not be opposed to automatically closing a fork-leaf as part of a merge, however, I think that it would require a user specified option to cause that to happen (see my previous post in this thread). _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
