On Tue, Apr 11, 2017 at 2:31 PM, David Mason <dma...@ryerson.ca> wrote: > > On 11 April 2017 at 14:34, Scott Robison <sc...@casaderobison.com> wrote: >> >> No, it is an explicit command clearly stating the user's desire for >> exclusion of these files *that are not already under source control*. >> The fact that the user does not remember or did not realize they >> issues conflicting commands does not mean that fossil should suddenly >> stop tracking the file, or so it seems to me. >> >> If a file was previously added to a repository (indicating a desire to >> keep track of modifications to the file), that is more important than >> ignoring the file. > > > I think --ignore should give an error if the --ignore matches a file already > in the repository. The current behaviour is clearly somewhat ambiguous.
It would be relatively easy to warn if a modified file matches the glob. Would you want it to search an entire checkout each and every time for all files that are monitored to see if they match? Should it always scan all files at every commit (even if they aren't in the current checkout) to find conflicts? I'm not trying to be flippant. I'm really not sure just how far to go down the rabbit hole, especially for a bit of functionality that has worked as expected for most people (presumably) for years (though maybe it isn't working the way anyone expects except for the few people who've weighed in defending it). > Alternately (or additionally!) a command that would check and report if > there is any file(s) that would match the --ignore or the ignore-glob flag > would be helpful. I was thinking about that earlier (well, a warning, not an error, which presumes you can't continue). Then the questions I put above came into my mind so I didn't bring it up. What would you suggest calling the command? -- Scott Robison _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
