Yep, now I understand and agree with you all. I guess you could call it supporting globbing, or scoped gdiff. I don't know if the present case is because globbing on the command line is expanded by the shell to a mondo list of files before fossil.exe gets them, in which case perhaps it needs a switch like --ignore-unchanged, or maybe changes it's behaviour to that automatically in the more-that-one-file case. Or maybe it always ignores unchanged files, but at least emits a message to stdout that it is skipping an unchangd file, so you don't think something is broken.
I wonder if in the meantime a script could be created to take the output of fossil changes and concoct a file list of just the changed files, and then invoke fossil gdiff with that? OK, now I'm really going to duck out of the conversation. Haha. -dave > -----Original Message----- > Of Dömötör Gulyás ... > Yes, that's exactly my use case, exacerbated by the fact that > FileMerge/opendiff are real slow when used from fossil/git/bzr per > file, taking on the order of seconds for every file it has to show, ... > On 25 September 2014 08:50, Tony Papadimitriou <to...@acm.org> wrote: > > Well, it may not seem like a problem if you compare a > single file that you > > know has no differences, but imagine youre checking a > specific directory > > with hundreds of files, only one or two of which have > changed. Fossil will ... _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
