Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
Ævar Arnfjörð Bjarmason writes: > 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. OK. I'll amend to add a few lines of note to the commit log and then merge it down. > 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. If you want to create, do not use "touch" that gives readers a false and confusing impression that you care about the timestamp of the thing being updated. If you say ">./$file", you can get an error from the shell just fine, I think. > test "$file" = "." && return 1 > # We cannot create a file with an empty filename. > test "$file" = "" && return 1 Likewise, as that would become ">./". > # 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!/[^/]+$!!') GNUism already pointed out, I think. > > # We touch "./$file" instead of "$file" because even an > # escaped "touch -- -" means something different. > if test "$file" != "$dirs" > then > mkdir -p -- "$dirs" 2>/dev/null && > touch -- "./$file" 2>/dev/null && > return 0 > else > touch -- "./$file" 2>/dev/null && > return 0 > fi > return 1 > } > > And then later on for the tests I do: > > # The existing test > test_expect_success "wildmatch: match '$text' '$pattern'" " > test-wildmatch wildmatch '$text' '$pattern' > " > > # My new test > if create_test_file "$text" > then > test_expect_success "wildmatch(ls): match '$pattern' '$text'" " > test_when_finished \" > rm -rf -- * && > git reset > \" && > git add -A && > >expect.err && > printf '%s' '$text' >expect && > git --glob-pathspecs ls-files -z -- '$pattern' > 2>actual.err | tr -d '\0' >actual && > test_cmp expect.err actual.err && > test_cmp expect actual > " > else > test_expect_failure "wildmatch(ls): match skip '$pattern' > '$text'" 'false' > fi > > This still needs to be cleaned up a bit to be parameterized (i.e. the > --glob-pathspecs argument, whether it should error etc.). > > It works for me on Linux, but I'm wondering if others see any issues > with the approach, does simply trying to create bizarro filenames on > some OSs cause issues? I don't think so, but let's make sure. Issues meaning that the test wants to see how a pathname with ^I in it works but create_test_file step would fail? Your above construct covers that with the if/then/else test_expect_failure/fi just fine, I think.
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
From: "Junio C Hamano" Sent: Monday, July 03, 2017 9:19 PM "Philip Oakley" writes: Am I right that the What's cooking is prepared by a script? Because I have to keep track of so many topics, its maintenance is heavily helped by a script. I do not think it is sensible to expect me to (or it would be good use of my time) correctly update the list of commits manually every time a topic is replaced with its new version. Definately. I was hoping that a 'contents list' element (at the point of sending the emails) could also be part of the automated scripting. But I consider the use of the script just like my use of Emacs to edit the final end result. Yes, I use tools to prepare it, and the tools know certain rules that I prefer to apply to the document, such as "a topic that has not been touched since the previous issue by default does not need its description updated." Does that answer your question? I see the script's location is given in a follow up response. I'll see what opportunities for a TOC there may be within the flow, though my local todo list is getting a bit long with other personal matters. -- Philip
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
On Mon, Jul 3, 2017 at 11:02 PM, Junio C Hamano wrote: > "Philip Oakley" writes: > >> From: "Junio C Hamano" >> >>> I am not sure what you are asking. Is this the command you are >>> looking for? >>> >>> $ grep -e "^[[*]" whats-cooking.txt >>> >> Ah, thanks. >> >> It does presume that one has extracted the email to the text file, >> which is easier on some systems and mail clients than others ;-) > > Perhaps you would want to find an e-mail client that can handle text > files better, then? ;-) > > If you are cloning and following along my tree from one of these > places: > > git://repo.or.cz/alt-git.git/ > git://git.kernel.org/pub/scm/git/git.git/ > git://github.com/git/git.git/ > > the 'todo' branch in these repositories keeps track of the > whats-cooking.txt report (among other things), so you can also: > > $ git cat-file -p origin/todo:whats-cooking.txt | > grep -e "^[[*]" > > to get the same effect. > FWIW: I have a script in my git dir, cat git/cookreport.sh git -C Meta pull origin todo Meta/cook -w with Meta being a repo tracking one of the URLs above. I might add a | grep -e "^[[*]" or add some scripting to verbose report my own topics. Thanks, Stefan
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
"Philip Oakley" writes: > From: "Junio C Hamano" > >> I am not sure what you are asking. Is this the command you are >> looking for? >> >> $ grep -e "^[[*]" whats-cooking.txt >> > Ah, thanks. > > It does presume that one has extracted the email to the text file, > which is easier on some systems and mail clients than others ;-) Perhaps you would want to find an e-mail client that can handle text files better, then? ;-) If you are cloning and following along my tree from one of these places: git://repo.or.cz/alt-git.git/ git://git.kernel.org/pub/scm/git/git.git/ git://github.com/git/git.git/ the 'todo' branch in these repositories keeps track of the whats-cooking.txt report (among other things), so you can also: $ git cat-file -p origin/todo:whats-cooking.txt | grep -e "^[[*]" to get the same effect.
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
"Philip Oakley" writes: > Am I right that the What's cooking is prepared by a script? Because I have to keep track of so many topics, its maintenance is heavily helped by a script. I do not think it is sensible to expect me to (or it would be good use of my time) correctly update the list of commits manually every time a topic is replaced with its new version. But I consider the use of the script just like my use of Emacs to edit the final end result. Yes, I use tools to prepare it, and the tools know certain rules that I prefer to apply to the document, such as "a topic that has not been touched since the previous issue by default does not need its description updated." Does that answer your question?
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
From: "Junio C Hamano" "Philip Oakley" writes: Junio, Is it possible to include a table of contents that lists the integration branches, split by your categories, to help find areas of interest? [Graduated to "master"] * topic list [New Topics] [Stalled] [Cooking] [Discarded] The TOC wouldn't need the [] or * markings if that's a problem. I am not sure what you are asking. Is this the command you are looking for? $ grep -e "^[[*]" whats-cooking.txt Ah, thanks. It does presume that one has extracted the email to the text file, which is easier on some systems and mail clients than others ;-) Am I right that the What's cooking is prepared by a script? -- Philip
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
"Philip Oakley" writes: > Junio, > Is it possible to include a table of contents that lists the > integration branches, split by your categories, to help find areas of > interest? > > [Graduated to "master"] > * topic list > [New Topics] > [Stalled] > [Cooking] > [Discarded] > > The TOC wouldn't need the [] or * markings if that's a problem. I am not sure what you are asking. Is this the command you are looking for? $ grep -e "^[[*]" whats-cooking.txt
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
From: "Junio C Hamano" Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Junio, Is it possible to include a table of contents that lists the integration branches, split by your categories, to help find areas of interest? [Graduated to "master"] * topic list [New Topics] [Stalled] [Cooking] [Discarded] The TOC wouldn't need the [] or * markings if that's a problem. -- Philip You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * ab/die-errors-in-threaded (2017-06-21) 1 commit
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
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)
Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
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!/[^/]+$!!') # We touch "./$file" instead of "$file" because even an # escaped "touch -- -" means something different. if test "$file" != "$dirs" then mkdir -p -- "$dirs" 2>/dev/null && touch -- "./$file" 2>/dev/null && return 0 else touch -- "./$file" 2>/dev/null && return 0 fi return 1 } And then later on for the tests I do: # The existing test test_expect_success "wildmatch: match '$text' '$pattern'" " test-wildmatch wildmatch '$text' '$pattern' " # My new test if create_test_file "$text" then test_expect_success "wildmatch(ls): match '$pattern' '$text'" " test_when_finished \" rm -rf -- * && git reset \" && git add -A && >expect.err && printf '%s' '$text' >expect && git --g
What's cooking in git.git (Jun 2017, #09; Fri, 30)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * ab/die-errors-in-threaded (2017-06-21) 1 commit (merged to 'next' on 2017-06-24 at 135fc4b963) + die(): stop hiding errors due to overzealous recursion guard Traditionally, the default die() routine had a code to prevent it from getting called multiple times, which interacted badly when a threaded program used it (one downside is that the real error may be hidden and instead the only error message given to the user may end up being "die recursion detected", which is not very useful). * ah/doc-pretty-color-auto-prefix (2017-06-24) 1 commit (merged to 'next' on 2017-06-26 at d7489fc831) + doc: clarify syntax for %C(auto,...) in pretty formats Doc update. * jc/pack-bitmap-unaligned (2017-06-26) 1 commit (merged to 'next' on 2017-06-28 at ad026b12a3) + pack-bitmap: don't perform unaligned memory access An unaligned 32-bit access in pack-bitmap code ahs been corrected. * ks/status-initial-commit (2017-06-21) 1 commit (merged to 'next' on 2017-06-24 at 940ffd5816) + status: contextually notify user about an initial commit "git status" has long shown essentially the same message as "git commit"; the message it gives while preparing for the root commit, i.e. "Initial commit", was hard to understand for some new users. Now it says "No commits yet" to stress more on the current status (rather than the commit the user is preparing for, which is more in line with the focus of "git commit"). * ks/submodule-add-doc (2017-06-22) 1 commit (merged to 'next' on 2017-06-24 at 26309b38f2) + Documentation/git-submodule: cleanup "add" section Doc update. * pw/rebase-i-regression-fix-tests (2017-06-23) 5 commits (merged to 'next' on 2017-06-23 at 835ae762f5) + t3420: fix under GETTEXT_POISON build (merged to 'next' on 2017-06-22 at d1dde1672a) + rebase: add more regression tests for console output + rebase: add regression tests for console output + rebase -i: add test for reflog message + sequencer: print autostash messages to stderr Fix a recent regression to "git rebase -i" and add tests that would have caught it and others. * rs/apply-validate-input (2017-06-27) 3 commits (merged to 'next' on 2017-06-28 at 81e006b50e) + apply: check git diffs for mutually exclusive header lines + apply: check git diffs for invalid file modes + apply: check git diffs for missing old filenames Tighten error checks for invalid "git apply" input. * vs/typofixes (2017-06-27) 1 commit (merged to 'next' on 2017-06-28 at 3d11e0b3fa) + Spelling fixes Many typofixes. -- [New Topics] * ab/grep-lose-opt-regflags (2017-06-30) 6 commits - grep: remove redundant REG_NEWLINE when compiling fixed regex - grep: remove regflags from the public grep_opt API - grep: remove redundant and verbose re-assignments to 0 - grep: remove redundant "fixed" field re-assignment to 0 - grep: adjust a redundant grep pattern type assignment - grep: remove redundant double assignment to 0 Code cleanup. Will merge to 'next'. * ks/commit-assuming-only-warning-removal (2017-06-30) 2 commits - commit-template: distinguish status information unconditionally - commit-template: remove outdated notice about explicit paths An old message shown in the commit log template was removed, as it has outlived its usefulness. Will merge to 'next'. * sb/hashmap-customize-comparison (2017-06-30) 3 commits - hashmap: migrate documentation from Documentation/technical into header - patch-ids.c: use hashmap correctly - hashmap.h: compare function has access to a data field (this branch is used by sb/diff-color-move.) Update the hashmap API so that data to customize the behaviour of the comparison function can be specified at the time a hashmap is initialized. This fixes a bug in patch-ids that may have caused segfault. * sb/merge-recursive-code-cleanup (2017-06-30) 1 commit - merge-recursive: use DIFF_XDL_SET macro Code clean-up. Will merge to 'next'. -- [Stalled] * mg/status-in-progress-info (2017-05-10) 2 commits - status --short --inprogress: spell it as --in-progress - status: show in-progress info for short status "git status" learns an option to report various operations (e.g. "merging") that the user is in the middle of. cf. * nd/worktree-move (2017-04-20) 6 commits - worktree remove: new command - worktree move: refuse to move worktrees with submodules - worktree move: accept