If you're avoiding "fossil branch new" because it doesn't automatically switch and you got confused about the behavior doesn't that help show that it makes sense to automatically switch by default?
I think the most "logical" design would be for the behavior of both branch creation methods to match as closely as possible. In this case both methods should switch the branch just created and tell the user it switched. If you want to retain previous behavior you can add a "--no-switch" flag which will keep you on your current branch. This way if somebody's legacy script were to break it would be a simple matter of adding the switch, rather than having to combine other commands to get the legacy behavior. On Tue, Feb 7, 2017 at 1:19 AM, Andy Bradford <amb-fos...@bradfords.org> wrote: > Thus said Richard Hipp on Mon, 06 Feb 2017 14:49:30 -0500: > > > Rather than break legacy scripts, perhaps a warning message that says > > "the new branch has been created but you are not currently on that > > branch - type "fossil update BRANCHNAME" to go there" or similar? > > I think a warning should suffice. While I have, on occasion, also > forgotten that ``fossil branch new'' doesn't automatically switch, I > have gotten into the habit of using ``fossil commit --branch'' because > it seems more natural, and doesn't create an extra artifact that exists > solely to create a branch (though I can understand why some would prefer > this method). > > Andy > -- > TAI64 timestamp: 4000000058996706 > > > _______________________________________________ > 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
