On Sat, Apr 18, 2015 at 12:19 PM, Ron W <ronw.m...@gmail.com> wrote: > On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland <mattrwell...@gmail.com> > wrote: > >> >> > #3 was looking problematic, possibly due to philosophy trumping >> pragmatism? Might be addressed now? >> > > This is a definition problem. > > To my thinking, any place a parent commit has 2 or more children on the > same branch is a fork. This seems very clear and unambiguous to me. Some > think this is too aggressive, so I will grant that closing fork-leaves is > sufficient to indicate explicit intent to resolve the fork. > > As to merging, a "branch-leaf" is not automatically closed by merging it > to anther branch, so why would merging automatically do anything to a > "fork-leaf" to make it not a fork-leaf? >
There is a --integrate switch to the merge command that closes the merged branch. Perhaps the addition of an "integrate" command that is essentially a merge with that option auto specified might be useful to those whose workflows seem to result in forks? There is also a leaves command, perhaps the addition of a --forks option would be useful, and a "forks" command (as has been suggested already) that is essentially the same as "leaves --forks". "leaves" by default only shows open leaves, but has --all and --closed options to pick other sets of leaves that might be useful, as well as --recompute. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
