One of the thinks that I most dislike of other VCS is the excess of options. Too many options means to much time reading the manuals and to much time remembering the possibilities of the tool.
Fossil is very good at it. It has the minimum set of options to make the tool useful. In my opinion, "fossil -M file commit" falls clearly into this category. I do not see it useful for scripting or external tools, as these tools can perfectly use the "-m message" option. And for the casual user, DRH option of saving automatically the comment and inserting it in the new commit is much more clever. An option that I would like to see in fossil, as it is not easy to perform in fossil without changing any file is a way to know what an update would do without actually doing it. I see two ways of doing it: fossil --dry-run update or fossil changes ?version? In the last case, there should be an easy way of knowing which is the version to which fossil would update by default RR 2009/12/9 Jeremy Cowgar <[email protected]>: > "D. Richard Hipp" <[email protected]> wrote: >> On Dec 9, 2009, at 5:00 PM, Stephan Beal wrote: >> >> > On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar <[email protected]> >> > wrote: >> > It seems that fossil is in need of two things: >> > >> > 1. Save the commit message to a file when the commit failed >> > 2. Provide a means of making fossil read the commit message from a >> > file >> > >> > i've just added -M/--comment-file which does #2. If there are no >> > objections to using -M/--comment-file for this, i will commit it. >> >> I was looking into storing the commit comment in the local _FOSSIL_ >> database and automatically reinitializing the commit message to the >> old comment on the second attempt to commit after the first attempt >> failed. In other words, make it fully automatic. Check back tomorrow >> and see if I don't have something working.... >> > > I don't think that the -M/--comment-file really has much to do with a failing > commit or the previous commit message. It would help with this problem, of > course, but your solution is equally as well. > > The place that I really see -M/--comment-file working is with scripting and > integration of fossil into 3rd party products. Many editors/IDE's provide the > ability to commit from the editor. They will bring up a dialog or query the > user in some manner, write the message to disk and call svn, cvs, hg or > whatever withe the commit message file. We too should provide that option if > we want to see fossil become more widely accepted. > > Now, on another note (a bit more personal to my work flow)... I will keep a > file open in my editor that is changes. I'll document my changes in that > file. Then, when I commit, I simply pass it on the command line. Thus, I > never forget what I did between commits. Once I commit, I clear the file and > start the process over again. > > On both accounts, the -M/--comment-file are necessary and a good idea, apart > from the problem being discussed. > > Jeremy > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
