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. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@xxxxxxxxxxxxxx>
cf. <xmqqo9tfff2w.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
"""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. <xmqqk2419rhg.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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)
