<file-name>.tags files are "more than hidden"

[conrad-heimbold]

I think it is a quite strange behaviour, that <file-name>.tags files can only be viewed / edited when explicitly requested.
ls -a does not show them.
I think, it would be better, if you could make them visible in ls -a, but not ls, by letting them start with a dot.

[StrumentiResistenti]

How would you then set them apart from real files? I mean, when you scan your repo with a tool, like a find store/t1/t2/@/ -exec ... or a cp -r store/t1/t2/@/ to extract some files, metafiles would be copied side by side with real files. How would you manage this case?

[conrad-heimbold]

Doing a cp -r some_directory/* will skip the dot files, and will only copy the non-hidden ones.
I am sure, find has an option to skip hidden files (correct me if I'm wrong), starting with a dot; or you could create such a filter by hand (enough tools for that on linux).
The dot is the designated sign for hidden files in UNIX/Linux. Creating some new paradigm (hidden files can only be viewed when explictly requested) creates too much complexity, IMHO.

EDIT: https://askubuntu.com/questions/266179/how-to-exclude-ignore-hidden-files-and-directories-in-a-wildcard-embedded-find#318211

[conrad-heimbold]

So, normal use of tagsistant is:

1. moving files outside of your tagsistant to a non-tagsistant directory
   => moving the hidden tag file should be no problem, it is actually rather good (IMHO), because you can make an easy granular backup of your file tags en passant.
2. moving files from one tagsistant repo to another
   => the approach suggested by you ( @StrumentiResistenti ) in issue syncing with other tagsistant instances on other devices #32 (syncing two tagsistant instances) already does copy the hidden (.)<file-name>.tags-files .
3. moving files inside one tagsistant repo
   => the hidden tag files should not be moved, otherwise we could get some conflicts, if the new tag directory (where the file gets moved to) contradicts a tagging mentioned in the hidden .tags file.

Merging two different (.)<file-name>.tags-files (see 2 and 3) should be / is already discussed in issue #32 , because they are a problem on its own.

[StrumentiResistenti]

Normal use of Tagsistant is storing files inside a repository for later retrieval and editing in place. Migration between repositories is a nice to have plus, but the very first priority should be keeping everyday activities easy and pleasant.

My opinion on listing .tags metafiles is that this feature should be controlled by a command line switch, like the presence of operators in triple tags (see issue #30). Forcing the user to perform complex filtering in find or to add a star to every cp is not desirable.

What if you forget one star or do the wrong filtering while migrating between repositories? You'll end up with a lot of real .tags files named after the metafiles in the source, having their own .tags.tags metafiles in the destination.

So I would go for the command line switch. If the user chooses to explicitly list the .tags files in every ls, he or she's supposed to know what this implies. Otherwise we'll keep the default behavior.