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

Reply via email to