Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to ignore subdirectories. #981

Closed
fuzzy7k opened this issue Nov 28, 2023 · 2 comments
Closed

Add the ability to ignore subdirectories. #981

fuzzy7k opened this issue Nov 28, 2023 · 2 comments
Labels
effort-medium issue is likely resolvable with <= 20h of effort enhancement issue is a request for a feature, and not a defect impact-low low importance wontfix maintainers choose not to work on this, but PR would still be considered

Comments

@fuzzy7k
Copy link

fuzzy7k commented Nov 28, 2023

It would be nice to be able to synchronize the contents of the root folder while ignoring all subdirectories. Something like what I was hoping one of the following would achieve.

ignore = Path */
ignore = Path ./*/
ignore = Name */

I understand that the PWD '.' is not understood. It's cross platform and I get that, but it seems that it would be beneficial to be able to signify the root somehow.

The bigger issue though, it seems, is that the separator '/' is not observed to signify a directory.

Maybe an ignoredir = * could be implemented in leu of using the separator.

@gdt gdt added enhancement issue is a request for a feature, and not a defect wontfix maintainers choose not to work on this, but PR would still be considered impact-low low importance effort-medium issue is likely resolvable with <= 20h of effort labels Nov 29, 2023
@gdt
Copy link
Collaborator

gdt commented Nov 29, 2023

Added to: https://github.com/bcpierce00/unison/wiki/Feature-Requests so this isn't lost; that's logically enhancement tickets, without the cognitive load of open tickets.

Unison is already too complicated, and there are a large number of possible requests for ways to control what's included and what's excluded. I think it's unlikely we'd want to add more, even with a ready-to-merge PR. If anything, something like the request to run a program to produce a list of what to include is more likely, as it could allow arbitrary choices with one mechanism. But please discuss on hackers@ if you want to pursue that; the issue tracker is only for fully-baked enhancements.

You are of course free to implement something and use it privately, and if you want to talk about a specific approach that you've at least prototyped to see if it really works on unison-hackers@, it would be interesting to see what others think.

@gdt gdt closed this as completed Nov 29, 2023
@tleedjarv
Copy link
Contributor

Without getting into any discussions, I feel it's worth adding a thought here. For future readers.

Features like this (including ones like CACHEDIR.TAG, etc.) need very detailed rules because the bidirectional nature of the sync means that both the client and server have to have the same understanding of the synced paths. Ignoring purely by path works because it works exactly the same on both client and server. Ignoring 'dynamically', by type (file, dir, ...) or by current contents of the fs (CACHEDIR.TAG or other magic files) is not that simple because the type (contents of the fs) of the same path can be different on client and server. Let's say you have a subdir named 'sub' on client. It will be ignored, as per this feature request. On the server you have a file named 'sub'. It will not be ignored because it's not a subdir. The file named 'sub' will now be synced to client, overwriting the subdir named 'sub'. (And no, simply ignoring 'sub' on both client and server is not the solution here.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort-medium issue is likely resolvable with <= 20h of effort enhancement issue is a request for a feature, and not a defect impact-low low importance wontfix maintainers choose not to work on this, but PR would still be considered
Projects
None yet
Development

No branches or pull requests

3 participants