Re: path = not supporting *

It IS a basic requirement, and as I outlined, it IS supported – with 
greater flexibility than usually needed.

I have several use cases myself, both for splitting up large file 
collections so as not to overload a small server, and for syncing to a 
laptop parts of a "main data" subfolder that contains a lot more that is 
only relevant for the desktop.
YMMV, but I generally find "ignore + ignorenot" more comfortable to reason 
about than rsync's "include + exclude".

The syntax is equivalent to Git's .gitignore syntax (Unison ignorenot Path 
... <=> Git !...), and more flexible than Mercurial's .hgignore, which 
AFAIK doesn't have an "ignorenot" equivalent.
The only boon those VCS offer, is that they accept a number of file 
arguments in the add/checkin call, where you can utilize the shell's 
wildcard expansion. That's okay for one-off calls (or wrapper shell 
scripts), but not very compatible with the concept of a synchronizer which 
should be able to be configured once and after that detect on its own what 
files are to be touched.

Whether to go forward with a Feature Request really hinges on if you can 
get used to the ignore/ignorenot way of picking material, or if that is so 
unintuitive that you strongly wish for another way. Technically, the tool 
is capable of fulfilling your use case as-is.


On Friday 19 July 2024 at 15:37:32 UTC+2 Mo B wrote:

Ok, I can describe my use case for that. I'm tracking part of a network 
drive that I don't administrate. I only like so sync parts of it to my 
local sync folder for faster access and offline availability. Therefore I 
need to filter the parts as usually done via globs.
I think this is a very basic requirement to any sync tool and is 
accomplished by rsync for instance, but also different VCS like git or 
hg... 

 

On Friday, July 19, 2024 at 3:18:18 PM UTC+2 Greg Troxel wrote:

Sebastian Schleussner <[email protected]> writes: 

> As far as I can see, all Unison settings accepting wildcards or regular 
> expressions, require PathSpec-type arguments that start with "Name", 
> "Path", "Regex", or "BelowPath". 
> "path" is in another class together with "root", "include", "force", and 
> "prefer". 
> 
> Changing the "path" setting to do the same as "ignore" and so on would 
> break countless profiles in the wild. 
> Changing the "path" setting to support wildcards without a keyword like 
> "Path" would introduce inconsistency into the syntax, and limit those who 
> want to use full regular expressions. 
> Making the keyword optional would provoke strange behaviour/error 
messages 
> if someone does want to sync a path such as "Name"... 
> 
> One solution to avoid breaking backward compatibility would be to 
introduce 
> a new setting such as "consider" that takes a PathSpec. 

Thanks for your analysis -- I find it is very helpful. 

So we conclude that unison is functioning as documented. And that 
perhaps, we could so one of 

1) introduce a Path2 = that takes a PathSpec instead of a literal path. 

2) add the keyword to Path. Because of your point that Path = Path would 
be ambiguous, make it a warning if there isn't one of the keywords, a 
space, and something more. Make sure that one of keywords matches 
exactly the current semantics. 

I sort of lean to the 2nd, but I am not sure it would be an overall win 
for users in terms of coping cost for many vs benefit for a few. And 
even if we decide it would be good, someone who cares would have to 
prepare a PR (that updates code, docs, tests, and is clean/rebased). 

> Personally, I am quite happy with the 'reason-ability' of a list of 
> "ignore"s and "ignorenot"s. 

Personally, I organize my files into dirs that I want to sync 
(~/shared/foo, for various foo), and do not try to sync my homedir. So 
all of this path stuff bothers me zero. I won't be working on it, and 
am speaking above as maintainer where I try to balance what's good for 
the entire set of users. 

 

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].