On 12/13/12 00:51, Themba Fletcher wrote: > I'd like to return to what I think should be the focus, which is > discussing what the "right thing" is for fossil to do. As a possible > compromise, the combination of a '-f' flag to fossil rm with the > ability to add aliases (mentioned as a possible feature by Richard > recently in another thread if I'm not mistaken) could solve this > completely. The default could remain as is, safe and conservative,
Could someone explain where the idea of added "safety" with the current behavior is? (I believe someone wrote an example a while back, but I don't remember what is was, and I can't find it again). As I stated in another mail, I have on a few occasion lost track of what operations I have performed due to fossil not immediately changing the working directory to reflect the changes I've requested. I see the current behavior as explicitly unsafe for that exact reason. Plus, no one is expecting rm to blindly remove files. To quote Martin Gagnon: -------------------- [---] I would expect: fossil rm <file>, to remove the file on checkout if the file is in sync with the repository, but command to fail if the file is locally modified. In the case where the user really want to delete change that never get committed, he can use: fossil rm -f <file> That way, there's no danger of accidental data lost. If you call "fossil rm" by mistake, file can be retrieve from previous version on the repository. -------------------- What's "unsafe" with that behavior compared to the behavior we have today? -- Kind regards, Jan Danielsson _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
