On 4/18/2017 2:21 PM, Barry Arthur wrote:
This is already possible with pathed globs in your
.fossil-settings/ignore-glob file.
On 19 April 2017 at 01:10, David Mason <dma...@ryerson.ca
<mailto:dma...@ryerson.ca>> wrote:
I have had to use Git for something this semester. It was mostly
a failure and I'll find a way to use fossil going forward.
That said, I noticed one feature of Git that was very useful, and
I'd love to see in Fossil. In Git, you can have a .gitignore file
in any directory and it applies to that directory and nested
sub-directories. This is very handy, especially for build
directories and executables. For example, if I have a directory
where I'm working on a program foo.c, I can (and do) exclude *.o
in my .ignore-glob, but I don't really want to put "foo" there
because I might have a file foo in another directory that I *do*
want in the repo. If I could put "foo" in a .fossil-ignore file -
in that particular directory - that would be very convenient. It
would also be useful in a target directory (for Rust/cargo) or a
_build directory (for Elixir/mix), where the only file you'd add
to the repo would be the .fossil-ignore, where you'd put "*" so
that nothing would be added.
It isn't well documented (yet, working on that right now) but the globs
are matched against the whole pathname of each file. Also, wild cards
are allowed (unlike Unix or Windows) to match path separators. This
allows a number of common cases to be easily handled in the single
.fossil-settings/ignore-glob file, stored alongside the other versioned
settings.
So a glob like "*.bak" or "*.o" works on files in the entire tree
because the "*" matches the path separators, just as a glob like
"*/_build/*" would match all the files in any "_build" folder below the
workspace root. As long as names are reasonably unlikely to collide,
that sort of glob can be set once and never need further maintenance
even if you re-organize or add a second thing to build.
Another thing that is not really said explicitly is that the ignore-glob
setting is mostly just a suggestion to fossil. It sets the default
behavior of some commands, but can usually be overridden either by
naming a file explicitly on the command line or by changing the entire
setting with the --ignore option to a command. Specifically, the
ignore-glob is not a kind of automatic "fossil rm".
I frequently include "*.dll" in my ignore-glob. If I needed to check in
some specific DLL (perhaps it was provided by a vendor as a binary only)
I can still say "fossil add some.dll" and then it will be picked up by
the next commit. Similarly if there were some file that an IDE
(stupidly) located in their build output folder that must be tracked,
you could still say "fossil add tool/_build/valuable-file.txt" even with
"*/_build/*" ignored.
One thing that is missing is the ability to have comments in the
ignore-glob to explain why some obscure file is being ignored. (Also
thinking about that, there are issues, but once settled it should not be
difficult.)
There has been discussion in the past of the merits of a single
project-wide ignore-glob vs individual files scattered in the tree. I
don't recall the details, but we settled on the single file in full
knowledge of it being different from other DVCS systems.
I think this would be a nice little project for someone who wants
to delve into the fossil codebase. I would, but I'm *way*
over-committed at the moment.
As usual, a working patch adds a *lot* of weight to an argument for a
feature.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
