Re: path = not supporting *

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].