One more thought. Perhaps, there's no need for a separate ignore list but just a bit different semantics of the existing 'ignore-glob'. Couldn't it just be that when a file (a set of files '*.whatever') is in the ignore-glob it behaves exactly like Richard suggested. From a user perspective that would be simpler -- just one list which means ignore yet not prevent from being added.
Cheers, Jacek 2012/7/2 Richard Hipp <[email protected]>: > > > On Mon, Jul 2, 2012 at 7:56 AM, Stephan Beal <[email protected]> wrote: >> >> On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal <[email protected]> >> wrote: >>> >>> i'm not personally convinced that an ignore list would completely solve >>> the problem (i think that just might lead to more confusion ("i changed the >>> file, why isn't it showing as changed?") and corresponding bug reports). But >>> it might be a solution or part of a solution. Can you elaborate on how you >>> imagine such a feature behaving? >> >> >> Maybe we could have a local list, similar to ignore-glob, like: >> >> fossil forget-local ...list...of...files... >> fossil remember-local ...list...of...files... (undoes the forget) >> >> "Forgotten" files would be excluded from commits unless they are >> explicitly named on the command-line (as opposed to being in a directory >> which was passed on the comment line). Fossil status "should probably" show >> them as changed, in any case. >> >> But what happens if the remote is updated? Do those files participate in >> merging (i suspect they should)? Are there other corner cases here? > > > I am willing to *consider* some option that says "do not commit these files, > even if they change, unless that are specifically named on the > command-line". I think this would be easy to implement by messing with the > is_selected()/if_selected() function. > > So, to use Stephan's example, if you marked Makefile as no-autocommit, and > there were changes to both Makefile and to file1.txt, "fossil commit" would > only check-in the changes on file1.txt. But "fossil commit Makefile *.txt" > would check-in changes to both file. Probably there should be another > command-line option such as "fossil commit --all" that also picks up > Makefile. The "changes" command should show the changes to Makefile, but > indicate that they are not checked in by default. The check-in comment > prompt string should indicate clearly that Makefile is omitted from the > check-in because of the setting and it was not specified on the > command-line. > > I don't think any changes are needed to update or merge or stash. "fossil > revert" is an interesting case - does it revert Makefile to the default, or > doesn't it? Maybe "fossil revert Makefile" or "fossil revert --all" is > required? > > Correction: I think "fossil changes" should only show Makefile if you give > it an option like "--all". Otherwise, "fossil all changes" (whose purpose > it to show check-outs with any changes that you have forgotten to check-in) > would give false hits for repos with only "Makefile-like" changes. > > >> >> >> -- >> ----- 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 >> > > > > -- > D. Richard Hipp > [email protected] > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
