You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Being a user of the BTRFS file system, I always want to exclude directories named .snapshot, otherwise I end up searching every snapshot on the drive, something which makes the search significantly longer (in real terms, it's 137 times as long - I measured it to be 44.059s vs 0.320s to find every file searching from the root), and I would rarely want to do (actually I've never had a purpose to do so).
This can easily be done by using either -E '/.snapshots/', implemented in an alias, or, more conveniently, I could simply add those directories to the $HOME/.config/fd/ignore config file, or an .fdignore file in the locations which contain snapshots.
However, my use-case is such that I almost never want to have files ignored from the search - in other words, I would generally also apply the -u argument. The -u argument has the effect of negating the effect of the fdignore/ignore config files.
This means that my only real means to achieve the desired effect is to use an alias which applies -u -E '/.snapshots/'. This is not really a problem - but having a configuration file for excludes, just as the configuration file for ignores, would be a 'nice-to-have'. It has occurred to me that this might also demand the need for a --no-exclude argument, to avoid said configuration files, just as the --no-ignore does for the ignore config files.
No pressure, no rush on this one - obviously I have a perfectly effective (although somewhat less convenient) workaround in the form of aliases, and I can use that in the mean time, or if you would prefer not to implement this FR at all... But it would be nice :)
Thanks in advance, and for an exceedingly fast replacement for ye olde find!
The text was updated successfully, but these errors were encountered:
pallaswept
changed the title
fdexclude/exclude configuration file, similar to fdignore/exclude configuration file
fdexclude/exclude configuration file, similar to fdignore/ignore configuration file
Feb 16, 2024
This is exactly the sort of thing fdignore was designed for. Would --no-ignore-vcs --hidden meet your need? That won't respect .gitignore files, and will show hidden files, but will still respect .fdignore and .ignore.
I don't really want to add yet another type of ignore file.
Besides adding complexity, I think this would be confusing for many users.
Being a user of the BTRFS file system, I always want to exclude directories named
.snapshot
, otherwise I end up searching every snapshot on the drive, something which makes the search significantly longer (in real terms, it's 137 times as long - I measured it to be 44.059s vs 0.320s to find every file searching from the root), and I would rarely want to do (actually I've never had a purpose to do so).This can easily be done by using either
-E '/.snapshots/'
, implemented in an alias, or, more conveniently, I could simply add those directories to the$HOME/.config/fd/ignore
config file, or an.fdignore
file in the locations which contain snapshots.However, my use-case is such that I almost never want to have files ignored from the search - in other words, I would generally also apply the
-u
argument. The-u
argument has the effect of negating the effect of thefdignore
/ignore
config files.This means that my only real means to achieve the desired effect is to use an alias which applies
-u -E '/.snapshots/'
. This is not really a problem - but having a configuration file for excludes, just as the configuration file for ignores, would be a 'nice-to-have'. It has occurred to me that this might also demand the need for a--no-exclude
argument, to avoid said configuration files, just as the--no-ignore
does for the ignore config files.No pressure, no rush on this one - obviously I have a perfectly effective (although somewhat less convenient) workaround in the form of aliases, and I can use that in the mean time, or if you would prefer not to implement this FR at all... But it would be nice :)
Thanks in advance, and for an exceedingly fast replacement for ye olde
find
!The text was updated successfully, but these errors were encountered: