Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)

[Junio C Hamano]

Æ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)

[Philip Oakley]

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)

[Stefan Beller]

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)

[Junio C Hamano]

"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)

[Junio C Hamano]

"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)

[Philip Oakley]

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)

[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

Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)

[Philip Oakley]

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)

[Torsten Bögershausen]

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)

[Ævar Arnfjörð Bjarmason]

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
\" &&
   

What's cooking in git.git (Jun 2017, #09; Fri, 30)

[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.

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