From: Torsten Bögershausen Date: Sat, 01 Jul 2017 12:59:02 GMT Subject: Re: What's cooking in git.git (Jun 2017, #09; Fri, 30) Message-ID: In-Reply-To: <87podkehcx.fsf@gmail.com> On 01/07/17 09:39, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jun 30 2017, Junio C. Hamano jotted: > >> * xz/send-email-batch-size (2017-05-23) 1 commit >> - send-email: --batch-size to work around some SMTP server limit >> >> "git send-email" learned to overcome some SMTP server limitation >> that does not allow many pieces of e-mails to be sent over a single >> session. >> >> Waiting for a response. >> cf. >> cf. >> >> """I thought your wish (which I found reasonable) was to record >> whatever information that would help us in the future in the log >> message? I was waiting for that to happen.""" > > I think it's fine in lieu of xiaoqiang zhao not being responsive to just > merge this as-is. The info that can help us in the future is in the ML > archive, which should be good enough. > >> * ab/strbuf-addftime-tzname-boolify (2017-06-24) 3 commits >> - REWORD ONLY SQUASH >> - strbuf: change an always NULL/"" strbuf_addftime() param to bool >> - strbuf.h comment: discuss strbuf_addftime() arguments in order >> >> strbuf_addftime() is further getting tweaked. >> >> Waiting for a response. >> cf. > > Meant to get to this after the last "What's Cooking", will submit > another version soon. > >> * ab/wildmatch (2017-06-23) 1 commit >> - wildmatch: remove unused wildopts parameter >> >> Prepare the wildmatch API for future enhancements to allow a >> pattern that is repeatedly matched against many strings to be >> precompiled. > > [...] > >> * ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits >> (merged to 'next' on 2017-06-26 at d026281517) >> + pathspec: die on empty strings as pathspec >> + t0027: do not use an empty string as a pathspec element >> >> The final step to make an empty string as a pathspec element >> illegal. We started this by first deprecating and warning a >> pathspec that has such an element in 2.11 (Nov 2016). >> >> Hopefully we can merge this down to the 'master' by the end of the >> year? A deprecation warning period that is about 1 year does not >> sound too bad. >> >> Will cook in 'next'. > > I have a longer patch series involving the "wildmatch: remove unused > wildopts parameter" patch (although not conflicting with it) which > assumes: > > 1. We'll merge down my "wildmatch: remove unused wildopts parameter" to > master (doesn't conflict with #3). > > 2. This ex/deprecate-empty-pathspec-as-match-all series will get in > > 3. My series, which among other things cleans up the wildmatch tests a > lot (and adds that new wildmatch pre-compile API that was ejected) > could be reviewed & merged down. > > The reason I'm waiting on #3 is because one of the things I'm doing is > improving the wildmatch tests to not only test via calling raw > wildmatch(), but also roundtripping via git-ls-files, and this will > conflict in a very minor way with #2 (the test will need to be changed > from "this warns + works differently" -> "this dies + doesn't work"). > > But if #2 is something that's going to cook until the end of the year > I'm going to submit this sooner, and then we can just handle the minor > conflict. Is cooking it for that long really the plan? > > Also, here's a minor RFC, as part of that series I need to create files > / directories for each of the tests now in the wildmatch tests, this > involves creating files like "?a?b", "a[]b", "$" etc. I.e. this won't > work on all platforms. > > So my WIP is, and I'd like feedback on the viability of the general approach: > > create_test_file() { > file=$1 > > # `touch .` will succeed but obviously not do what we intend > # here. > test "$file" = "." && return 1 > # We cannot create a file with an empty filename. > test "$file" = "" && return 1 > # The tests that are testing that e.g. foo//bar is matched by > # foo/*/bar can't be tested on filesystems since there's no > # way we're getting a double slash. > echo "$file" | grep -F '//' && return 1 > > dirs=$(echo "$file" | sed -r 's!/[^/]+$!!') sed -r is a GNU extension, isn't it ? http://pubs.opengroup.org/onlinepubs/7908799/xcu/sed.html This may work: sed -e 's!/[^/][^/]*$!!') (The rest looks good - at first glance)