fd
fd copied to clipboard
Add the possibility to include ignored file but exclude files from .gitignore
Use case: in my repository, I have a .git
folder (ignored by default by fd) and also some config files tracked by git, for instance .gitlab-ci.yml
and .gitignore
.
I'd like to have a way to include this last file, even though it's technically hidden.
As a workaround, I'm adding:
!.gitlab-ci.yml
etc in my .gitignore for each file I want to get.
Does fd -H
work?
fd -H shows all hidden files, even if ignored by git.
To elaborate, the behaviour I'd like to have:
- outside of a git repo, same as actual
- inside a "git repo", I want to:
- ignore every vcs ignored files (.git, build, dist, everything ignored by
.gitignore
) - but get every files not ignored by git (so tracked and untracked but not ignored, everything potentially showing in
git status
), whether hidden (starting with.
) or not.
- ignore every vcs ignored files (.git, build, dist, everything ignored by
From the shell, I can get such a list with ( git status --short| grep '^?' | cut -d\ -f2- && git ls-files ) | sort -u
for instance.
To give a bit more context, the reason why I ask this of fd, is because it's used by fzf (by default) and in turn by telescope
vim plugin.
I can workaround this for fzf and fzf-dependent tools in 2 ways:
- setting
FZF_DEFAULT_COMMAND
to a shell script that would use the above command in a git repo, other similar command in other vcs and fallback to fd outside a vcs folder (I haven't written such a script yet). - or explicitly not ignoring files in
.gitignore
. For instance, if I add!.gitlab-ci.yml
, for some reasons, fd then picks it up.
Imho, it'd be nicer to have this behavior with a fd options, for instance a --ignore-vcs-only
, if you want to keep the backward compatibility for --ignore-vcs
And fd --ignore-vcs
doesn't show hidden files not ignored by git.
fd -H shows all hidden files, even if ignored by git.
Not really:
tavianator@tachyon $ echo .foo > .gitignore
tavianator@tachyon $ touch .foo .bar
tavianator@tachyon $ fd -H
.bar
.gitignore
.git/
.git/...
It prints .bar
but not .foo
. It does include .git
, which might be surprising. See https://github.com/sharkdp/fd/issues/204. You could add .git
to .fdignore
or .gitignore
if you want.
The behaviour when explicitly negating things in .gitignore
is arguably a bug: https://github.com/sharkdp/fd/issues/1266
I ended up putting .git
in ~/.fdignore
and export FZF_DEFAULT_COMMAND="fd -H"
in my shell rc. At least for git, it nearly does what I want (because I'd like to keep hiding files outside of a git repo, ideally, but that's ok I can live with this). Thanks for your help @tavianator!
Feel free to close this or let this open if my idea of a new option seems good to you.
It sounds like what you really want is an option that means "show hidden files only if they are in a git repository". Because if you are in a git repository, hidden files that are ignored are likely significant.
I would actually also find such an option useful, for similar reasons. I'm not sure what a good name for such an option would be.
It would be nearly perfect, with the nuance that I don't care about hidden files that are not tracked by git. Actually the ideal solution is really the union of untracked, visible files (so default behavior of fd) plus every files known to git, hidden or not. I'd argue that could be the default, but it would be a breaking change...
To stay on a backward compatible solution, maybe the option could be called --all-vcs-files
("always include files tracked by a vcs")?
the ideal solution is really the union of untracked, visible files (so default behavior of fd) plus every files known to git, hidden or not
My 2 cents: this is a very specific usage case, so I don't think it suits well the general purpose of fd
.
I see fd
more as a tool to help users find files and visualize folders in the CLI, in contrast to being a Swiss knife for scripting (I'd put that as the second priority).
You care about the untracked that's unhidden, but not the untracked that's hidden, that's odd, or at least I've never seen this pattern before, I'd expect such granularity from a custom script that pipes output to filtering tools (cool little project idea).
You care about the untracked that's unhidden, but not the untracked that's hidden, that's odd, or at least I've never seen this pattern before
I care about the unhidden untracked, because they are not hidden. I don't think it's odd. And it's also what fd does by default already. This issue is about the tracked starting with .
(so hidden).
This issue is about the tracked starting with . (so hidden).
I know what the issue is about.
What you want:
- ✅ tracked.
- ✅ tracked hidden. (current: ❌)
- ✅ untracked.
- ❌ untracked hidden.
I just said it's odd that you want 2 but not 4, in other words, I've never seen this pattern before, anywhere.
Why is that odd?
Consider a repo where you want to see things like:
- .github
- .editorconfig
- .gitattributes
- .eslintignore
- etc.
but you don't want to see things like:
- .git
- .cache
- .my-build-tool-outputs
- etc.
The first list has code and configuration I care about, and may want to change. The latter are things that I usually don't care about, and are usually generated by something else.
(Did you close this by accident?)
Consider a repo where you want to see things like:
- .github
- .editorconfig
- .gitattributes
- .eslintignore
- etc.
but you don't want to see things like:
- .git
- .cache
- .my-build-tool-outputs
- etc.
The first list has code and configuration I care about, and may want to change. The latter are things that I usually don't care about, and are usually generated by something else.
The latter are things that I usually don't care about, and are usually generated by something else.
That is solved by .gitignore
.
The files .cache
and .my-build-tool-outputs
should always go in .gitignore
.
But .github
and .eslintignore
shouldn't, they're part of the repository content.
fd -H
handles this case nicely :white_flower: (except for .git/
).
Ah yes. Good point, I was including gitignored files in "untracked" category. So I don't really have a usecase for this either besides.git
Including .git
folder in the gitignored filtering would be enough, from my POV. Indeed, I agree that .gitignore
solves the use case. The only case it does not solve (for me) is indeed the 4th point, but:
- I can always use
git add --intent-to-add
in the case I'm going to commit a new file - it's because I'm messy in my git repo and keep files there, but that's just me.
From my POV this can probably be closed and I'll use fd -H
from now on (with something in .fdignore
until #1387 is solved). Thanks to all!