Re: path = not supporting *

Thanks, Greg.

TBH, iff a decision to implement something new is made, I would still lean 
to the 1st (new setting – "consider", "path2", "pathw" or whatever):
* Consistency: Otherwise someone new to Unison could easily get a 
misleading mental model of the syntax if they experienced that "path = 
some/files.txt" works, then getting confused about getting an error for 
"ignore = something/else".
* Consider the legacy/beginner case "path = Path to the lake/Designs". A 
keyword-optional Unison would happily parse that as a PathSpec "to the 
lake/Designs" without sensing any reason to issue a warning. ;)

/Sebastian


On Friday 19 July 2024 at 15:18:18 UTC+2 Greg Troxel wrote:

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