On Mon, Apr 10, 2017 at 1:05 PM, Thomas <tho...@dateiliste.com> wrote: > On 2017-04-10 20:00, Scott Robison wrote: >> >> On Apr 10, 2017 12:48 PM, "Thomas" <tho...@dateiliste.com >> <mailto:tho...@dateiliste.com>> wrote: >> Example of .fossil-settings\ignore-glob: >> *.obj >> *.tlog >> *.VC.db >> >> The real file of course contains a much bigger list. I only picked >> these three masks as an example. >> >> Fossil happily ignores the .obj files (and many others), but no >> matter how hard I try, it keeps adding all .tlog and all .VC.db >> files (and it ignores many others too). I can't figure out a pattern >> that would tell me why some files/filters are accepted and work as >> advertised in the ignore-glob, others aren't. >> >> Is there anything I overlooked? >> >> Any help or idea is highly appreciated. >> >> >> I think it reads those from the repo, so you won't see anything until >> you've committed the files once or after changes are made. > > > The files it ignores (.obj, .iobj, etc) are neither in the local repository > nor in the remote one. > > The files it doesn't ignore (.VC.db, .log, .tlog, tec) are in both, the > local and the remote repository. > > I got autosnyc on. Sorry, I probably should have mentioned this.
No problem, I was more brief that I maybe should have been because I was just about to head into a meeting. So here is what I was trying to say: Let's say you have a repo named bob. You have not yet committed any .fossil-settings files. You create the .fossil-settings files then run addremove and commit. The addremove command will not recognize any of the files you are ignoring at this point because you've never committed the .fossil-settings files themselves. Let's say you have set some glob patterns in the past, either through the web interface, the command line, or via a .fossil-settings file. Then you update the .fossil-settings files, run addremove and commit. Any changes you made to the .fossil-settings files will not be honored because you've not committed them. It very well may be that this is not what you are doing, but I can see how it would not be intuitive that fossil will not use the .fossil-settings file you have updated in the opened working copy but not yet committed. If you *are* doing this, maybe you would be satisfied with a flow like this: 1. update .fossil-settings 2. add (if necessary) and commit those changes 3. now run addremove for the entire working copy 4. now commit those changes. -- Scott Robison _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
