Fossil SCM

I recently upgraded from version 1.24 and noticed a break or a change in behavior on how the binary-glob works. I looked in open tickets and all tickets as well as the change log for 1.25 to see if this was a deliberate change but I didn't see note of it, perhaps I missed it?

I create a new repo, add my settings, checkin settings, add my project files which contain binary files like .lnk and .bin, then try to commit my initial check in. I then receive the following even though I have both .bin and .lnk in .fossil-settings\binary-glob. If I change back to the 1.24 executable I do not experience the issue.

"fossil commit -m "mbp: Initial check in of NI PXI-5412 example code" fossil: SQLITE_IOERR: delayed 25ms for lock/sharing conflict ../../Waveforms/SineI16BigEndian_1000.bin contains binary data. Use --no-warnings or the " binary-glob" setting to disable this warning. Commit anyhow (a=all/y/N)? n fossil: Abandoning commit due to binary data in ../../Waveforms/SineI16BigEndian_1000.bin"

It looks like the glob_expr() function (src/glob.c line 17) doesn't handle newlines as it should. Proposed fix in [ticket-ed23ef59cf] branch. I'm not sure if this fix handles quotes correctly, but at least it's a start.

Workaround: don't use newlines to separate multiple entries, use ','

I did a bisect in order to find out when this bug was introduced. The result was: [0c7c61447f]

Guess what. This commit adds the binary warning to the commit dialog, previously the function glob_expr was only used to handle "crnl-glob". So, the 'bug' (glob_expr doesn't handle newlines as glob_create does) has always been there, but no-one noticed it because the commit dialog didn't use it. It was only used in the diff logic.

Anyone having objections to merging [e0e88821bd] to trunk?

Fixed in trunk