2013/1/23 Richard Hipp <[email protected]> > > > On Wed, Jan 23, 2013 at 5:56 AM, Petr P <[email protected]> wrote: > >> Hi, when commiting with fossil, I miss git's "git commit -v" feature that >> appends the diff of changes being commited to the file where I edit a >> commit message. This way, I can see what exactly I'm commiting when typing >> the message. It saved me from a wrong commit a few times. Of course, I >> could call "fossil diff" before (and I do that now), but it's not that >> convenient. Would it be difficult to add this to fossil? I briefly looked >> at the sources and it seems to me that it'd be enough to modify one diff >> function to allow writing output to a file (instead of just stdout) and >> calling it during the commit phase. I can try to do that myself, if there >> is a chance it'll be accepted. >> > > I think that's a good idea. > > It might be easier to run "fossil diff" as a subcommand using > fossil_system(), and save the output into a temporary file, or just append > it to the end of the template commit message. It probably would not be too > difficult to add a flag to the "fossil diff" command that caused it to > prepend "# " to every line of output, making the resulting text part of the > commit message that is ignored. >
Is fossil_system() safe to use for invoking another instance of "fossil"? Is this idea used already in some command? I'd be worried about things like platform-independence, security (ensuring that the invoked 'fossil' executable is the same as the one running) etc. Modifying diff_file (or something like that) to append its output to a file seems safer to me. Git adds the diff without the "#" mark. I'm not sure how it recognizes the diff, maybe it ignores everything after a line starting with "diff". I think one of the advantages is that it's easier to read for humans and also easier for editors to do proper syntax highlighting (like vim). Maybe a solution would be to add something like SVN has: "# Everything below this line is ignored". > > On the other hand, your original plan might work out better - modify the > built-in differ so that it can be directed to write into a memory buffer > rather than a file. Though, that case might cause complications if the > user has configured their fossil to use an external diff program of some > kind. > Won't keeping the diff in memory be a potential scalability problem? Although it won't happen often, I can imagine a huge diff, for example after reformatting the whole code of a big project. Redirecting it to a file that is being created anyway seems better to me.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
