on Friday 07 July 2017 at 22:14, Andy Bradford wrote: > Thus said Natacha Port? on Fri, 07 Jul 2017 09:43:56 -0000: > > > (3) "fossil checkout --keep", which is advertised as changing the > > "current commit" pointer without touching the working directory, but > > bails out of there are unsaved changes. > > (4) "fossil checkout --keep --froce", which changes the "current commit" > > pointer whithout touching the working directory and accepts to do so > > when there are unsaved changes. > > One must keep in mind that both (3) and (4) will not attempt to merge > any changes that you have made to managed files. This means that if you > have made significant changes to files that are not the same between the > current checkout and the new desired target checkout, then you will end > up with a huge diff to figure out.
Indeed. Why I ask a tool to do something, I expect to have to deal with the consequences of what I'm asking it to do. > > Since "fossil checkout --keep" is not supposed to change the working > > checkout, is it rightfully considered dangerous as "fossil checkout" > > without flag? Or should the code be updated to have "fossil checkout > > --keep" not fail out when there are unsaved changes? > > Are you suggesting that --keep should imply --force because --keep is > non-destructive? Whereas, on the other hand, ``fossil checkout --force'' > can be destructive? Indeed I am. That or have the --keep flag not trigger the unsaved change check, in case these wordings happen to not be exactly equivalent (the code is not obvious on that point). Natasha _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
