On 8/3/2015 3:24 PM, Warren Young wrote: > On Aug 3, 2015, at 1:31 PM, Andy Goth <[email protected]> wrote: >> Usually I don't bother, especially if there have been check-ins since >> the error was committed. > > Wouldn’t a better solution to that problem be a continuous integration > system, so you get an email shortly after committing a change that > breaks the build? Then your risk window shrinks to the CI rebuild > time.
You're suggesting an external, automated method of auditing check-ins, which I think is a good idea but beyond the scope of the Fossil SCM. I'm suggesting a way for Fossil to warn the user prior to committing a bad check-in in the first place. I was also writing about how to recover from a bad check-in. It can be moved to a hidden branch then retry the commit, or it can be left alone and followed up with a check-in that corrects it. >> Maybe even merge the lists, prefixing each line with EXTRA or MISSING >> or NON_UTF8 or CRLF. > > I rarely run into this one, since I normally just say “all” when asked > if I really meant to do that, since I usually did mean to. Then I go > and hack on the relevant *-glob setting. I'm more likely to hit bad UTF-8 than CRLF because I know to fix line endings when I import code whereas I tend to rely on Fossil to detect character encodings. Fossil can't convert bad UTF-8 like it can CRLF. So I will want a complete list of files that need me to fix by hand. Maybe split this functionality from the commit command and make a new warning or audit or check command which will print all the things that may prevent a commit from going forward, but also toss in extra files if the check-extras setting is enabled. >> does Fossil squawk about files using CR alone >> or LFCR? > > Yes: Thanks for looking into it. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
