2012/1/31 Jacek Cała <[email protected]> > > fossil commit -m "Some changes in dir" --filerange [2-3] > > or > > > fossil commit -m "Some changes in somefiles" --filerange 1,3 >
That's an interesting idea. The first syntax wouldn't be ideal because the [ and ] operators actually mean something to unix shells, but the second form, including 1-3 could be done. In fact i have some C code for parsing ranges like that in another project of mine, and it would be easy enough to port that in. The only problem i see at the moment is that such numbers are transient - they potentially change with any given file-level change. e.g. fossil changes 1 abc 2 def 3 xyz then i edit file "lmn" and run: fossil commit -m '...' 1-3 it "could be" (and likely will be) that file lmn is now #3 (assuming lexical ordering). Fossil "could", as part of "changes" or "status" record the last known list, and check that list before allowing a commit to be performed, and erroring out if (A) the list has changed since the last "changes"/"status" and (B) the user supplied a numeric list on the CLI. A secondary (but probably minor) problem is that this syntax prohibits numerically named files (probably a rarity, but someone out there probably has 1 or 2 of them (no pun intended). useful. Also, could Richard, Stephan and others who spent more time on > i think that's the first time someone has accused me of being familiar with the fossil innards ;). i think the idea is interesting and quite possibly doable with relatively little effort, but i also know that i tend to miss some of the "bigger picture" pitfalls which others on this list historically point out for, so i'd like to wait and see what some of the others say... -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
