list: ignores .dvcignore with path option

[gurobokum]

Based on the conversation
If you have a structure:

.dvc/
.dvcignore
data/
    a
    b
    c

And .dvcignore contains c, then your code will list all of the files in data, while c should be skipped

dvc list . data
a
b
c

but expects

a
b

$ dvc --version
0.86.5+a9bc65.mod

[shcheklein]

since we include all files (Git-tracked + DVC), does it makes sense to just colorize them in a different way?

[gurobokum]

since we include all files (Git-tracked + DVC), does it makes sense to just colorize them in a different way?

At this moment we colorize by default (rs=0:di=01;34:ex=01;32):

1. folder di
2. +x flag ex

we had a conversation with @efiop about default color for outs and .dvc and at this moment it's disabled default color for such types cause it can overlap with existed user theme

Dvc files can be colored as

1. outputs with out key -> export LS_COLORS="out=01;37:$LS_COLORS"
2. dvc files with *.dvc key -> export LS_COLORS="*.dvc=01;31:$LS_COLORS"

I think it make sense to add default colors for out and *.dvc files, cause IMHO the case when it overlaps with theme is really rare and can be customized by user.

[shcheklein]

I meant to colorize .dvcignored with dark grey or something, but include the in the output if they are Git-tracked.

[skshetry]

Dark grey makes it really hard to read on terminals (maybe, that's what we want).

[shcheklein]

Dark grey makes it really hard to read on terminals (maybe, that's what we want).

yes, I agree. But since we discuss here to hide them, it should be a better option.

My main point - please, let's not hide them.

[skshetry]

But, I think, we should respect user trying to explicitly ignore stuffs. Well, ignore means ignore.

[shcheklein]

@skshetry ignore means it is just a regular Git-tracked file, that we show. We can annotate them somehow or colorize (to emphasize that they are .dvcignored), but I don't any reason to hide Git-tracked files.

Btw, can I do dvc get ... some-dvc-ignored-file?

[gurobokum]

but include the in the output if they are Git-tracked.

I don't think that we should respect .dvcignore if it's Git-tracked file for dvc list

There are 2 options:

1. File is a DVC-tracked and added to .dvcignore
   The case is not covered, and the issue about this case. I think applying additional coloring can make sense, but what it can means? Ignored outs aren't able to get/import?
2. File is a Git-tracked and added to .dvcignore
   I think the file should be printed as a simple file. In what case not dvc outs can be added to .dvcignore?

[shcheklein]

File is a DVC-tracked and added to .dvcignore

It's a strange case. Or I'm missing something. Usually if file is .dvcignored it is not DVC-tracked.

File is a Git-tracked and added to .dvcignore

agreed. I would show them as a regular Git-tracked file/directory for now.

I'm not sure to be honest that we have something besides 2.

[gurobokum]

Hence I think the issue should be closed as irrelevant? Could you please share your thoughts here @Suor

[Suor]

Current implementation hides dvcignored files in some cases and shows in another ones. Judging by code the intention was to always hide, i.e. CleanTree is used for listing files. But since CleanTree is used wrong it doesn't respect .dvcignore files outside of the listed dir.

So there are separate questions:

• should we show dvcignored files in dvc list?
• should we color them somehow?

Any way we answer them current behavior is wrong and should be fixed.

[gurobokum]

Current implementation hides dvcignored files in some cases and shows in another ones

Based on the comment #3431 (comment) we can only have a Git-tracked file (or dir with Git-file) that is included in .dvcignore. It's never ignored, in what case you see it's hidden in the output?
As I see .dvcignore doesn't relate to listing somehow

should we show dvcignored files in dvc list

yes, it's a simple Git-tracked file. Temporary files (not commited) are not listed with dvc list

should we color them somehow?

I don't see the reason to add additional coloring for them

[karajan1001]

Already fixed in some previous version. close it.