On Mon, 18 Apr 2011 09:44:51 +0200 Arjen Markus <[email protected]> wrote:
> I have a few comments (and not realy much more than that) on the > way Fossil implements the editing of commit messages: > > - I noticed that the choice of editor seems to be a global setting > in the repository. At least, that is the behaviour I observe > with one repository (but that may be peculiar to that particular > project). As editors are a highly personal choice, I would expect > this to be a user-defined setting. This would mean fossil should start keeping a per-user configuration file somewhere under %USERPROFILE% which it does not at the moment as far as I can tell. On the other hand, it already maintains there a database which records pathnames of all fossil repos created/cloned by the user... On the other hand, fossil set editor gvim.exe produces fossil settings|grep edit editor (local) gvim.exe which hints that this setting is local and won't be pushed to a remote repo. So to me it seems the only real problem is that if you're unwilling to set the EDITOR or VISUAL environment variables you have to repeat the editor setting for each of your repositories. > - I noticed that when I compile Fossil for MinGW, the default editor > is not notepad in the absence of EDITOR etc. environment variables, > but a command-line interface. I think notepad, whatever you think > of it, would be a more natural choice. To me, that command line interface appeared to be a quite sensible thing: a commit message is usually short, and if you don't like the builtin editor interface you just hit Ctrl-C and make the necessary configuration tweaks. On the other hand, hardcoding notepad.exe appears to be too simple-minded to me: a more compliant approach would be to use Shell API to open the saved temporary file with the commit message using whatever tool the user associated with the .txt extension. > - As I mostly work on Windows, my editor is set to write CR/LF > line-endings. If I commit files that I forgot to save with LF > line-endings, I get a question about this - but only for the > first file. If I then break off the commit, repair this and try > again, a message follows about the next file. > > Would it be possible to simply scan all the files to be committed > and present a list of files that have a CR/LF issue, so that you > can repair all of them at once? Not addressing exactly this problem, but are you aware about the "crnl-glob" setting which can be used to allow committing of files with CRLF line endings without any warnings. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
