I'm using fossil for the first time, on a new project -- it hurts how pragmatic and elegant fossil is, I had to try it. Over the years, I've developed some habits from hg and git that I can't seems to reconcile with how fossil does things. Can somebody tell me what I'm missing or how my workflow needs to adapt? I seem to be doing two steps for tasks that I preform dozens of times a day and that took one step in both git and hg.
rm, mv: Managing files under source control in fossil is tedious, since I have to do every operation twice. One time for fossil and one time for the file system. Ex: $ fossil rm file1 DELETED file1 $ ls file1 $ rm file1 Is there a reason behind this design decision? I'm on the verge of creating my own wrapper script around fossil to get this done in one step. Especially at early stages of the project I perform these operations frequently. It just feels wrong to have to say the same thing (as I see it) twice. fossil changes; fossil extra; : These guys I just dont get. I had to write an alias in my bashrc just because it was getting really annoying. I use 'hg status' and 'git status' multiple times before I commit to get an instant look at what im doing: what file have I touched AND what new files have I created that I need to remember to add to source control. With fossil I have to execute two commands to get the same amount of information. If I do just fossil changes, I inevitably forget to 'fossil add' something. Again, this is especially relevant during the early stages of a project where things change much more dramatically (at least in my case.) To recap: Why not perform file system changes when fossil is instructed to delete or rename a file? Why not have a single command that gives you ALL differences between your working tree and the repository? Best, -Nick _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users