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.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
