Thus said Ron W on Thu, 16 Apr 2015 21:04:12 -0400: > I disagree. While it might be the most common case, merging does not > explicitly state any intent beyond the merge itself, even a full > merge.
After one has merged a fork, does ``fossil merge'' report that there are any more forks to be merged on the branch? If not, then does not Fossil intend that it is no longer a fork? > After all, a merge doesn't automatically close a named branch. So why > would a merge automatically make a "fork" not a fork? As I tried to point out earlier, ``close'' is a special term in Fossil. The only time a branch is ``closed'' is if it has a ``closed'' tag on it. Merging the branch does not ``close'' the branch. It is still a branch because new commits against its leaf are still allowed. If you merge a fork, commits against it are no longer allowed, at least not without another --allow-fork (or an accident). Neither does merging a fork ``close'' the fork, but it is it no longer a fork by virtue of the fact that it has been merged into itself. To make it a fork again, one would have to commit against the node that was merged. One can have a fork on a non-trunk branch too: http://fossil.bradfords.org:8080/timeline > Closing it or making it the start of a new, named branch explicitly > indicate an intent to remove "fork" status. Why does merging not removes ``fork'' status? If it hasn't changed status, why would ``fossil merge'' cease to to think that there is a fork to merge. ``fossil help merge'' says: ``If the VERSION argument is omitted, then Fossil attempts to find a recent fork on the current branch to merge.'' For Fossil to attempt to find a recent fork, must it not have a working definition of just what a fork is first? Notice also that Fossil does not label a fork that has been merged a leaf. But a branch that has been merged is still considered a leaf (or in other words an active named fork) because the ``closed'' tag has not been imposed upon it. Once ``closed'' the branch will be a ``closed leaf.'' So clearly Fossil does treat a ``fork leaf'' differently from a ``branch leaf.'' Oddly enough, I'm not sure if this is a bug... but if I update to: http://fossil.bradfords.org:8080/info/ddbeee499bb3cee9 ``fossil update'' does not complaing about there being multiple descendants. However, ``fossil merge'' actually does merge in the Closed leaf that is part of the fork. Not sure if this is actually intended behavior, but it does seem that ``fossil merge'' treats the fork differently than ``fossil update'' does. Thanks for the interesting discussion. Definitely good to flesh out the definitions we're using. Thanks, Andy -- TAI64 timestamp: 4000000055306bbf _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
