On Mon, Apr 10, 2017 at 1:58 PM, Thomas <tho...@dateiliste.com> wrote: > On 2017-04-10 20:34, Scott Robison wrote: >> >> On Mon, Apr 10, 2017 at 1:05 PM, Thomas <tho...@dateiliste.com> wrote: >>> >>> On 2017-04-10 20:00, Scott Robison wrote: >> >> 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. > > > Thanks for your extensive explanation. You're right, I would have never > expected it to work like this. In fact, I believe if it really behaves as > you described it, that's something that should be mentioned in the > documentation. > > I can't imagine I'd be the only or first one who'd stumble over this. It > means that whatever you do or want to do the first commit automatically > stores all files unconditionally in the repository. > > I'd even go as far as to say this defeats the whole idea of having (only) > these files in the first place. Or, in other words, what good is an > exclusion or filter list that doesn't exclude or filter right from the > start? > > >> 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. > > > I am using these files at the moment, yes. > > But even before the first addremove or commit I had the .VC.db or .tlog > files exluded with the --ignore parameter on the command line for addremove. > So, no this behavior can't be the reason why Fossil ignores some files but > not others. > > fossil addremove > and > fossil commit > must have been run hundreds of times now, and the files are still updated in > the repository every time addremove is performed.
I'm running on very little sleep, so I hope I'm helping more than just rambling. Anyway, I just created an empty test repo: > fossil init test.fossil then opened it > fossil open test.fossil then created three files > echo '*.a' > .fossil-settings\ignore-glob > echo a > a.a > echo b > b.b then ran fossil addremove and it only added b.b. My guess is that since I last cared about that bit of functionality, someone changed it to work more intuitively. Given that .fossil-settings\ignore-glob is in a hidden dot folder, addremove does not automatically add the ignore-glob file itself. I did that separately. Next I added a.a explicitly (it warned me and I said okay) and committed. Then I made a change to a.a and it was identified as a change for the next commit. So my best guess at the moment is: During one of your earlier attempts at adding things, you added a bunch of files and committed them to the repo. Now that those files are in the repo, fossil will not ignore them because they are part of the repo. If you were to remove the files from the work directory so that fossil was no longer tracking them, commit those changes, then try addremove again, it might work more to your liking. At least, that worked for me here with a simple little repo with only a few files in it. My version: "This is fossil version 2.1 [83e3445f67] 2017-03-10 17:07:08 UTC" -- Scott Robison _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
