Re: What's cooking in git.git (May 2017, #06; Mon, 22)

[Junio C Hamano]

Duy Nguyen  writes:

> On Mon, May 22, 2017 at 1:11 PM, Junio C Hamano  wrote:
>> * nd/fopen-errors (2017-05-09) 23 commits
>>  - t1308: add a test case on open a config directory
>>  - config.c: handle error on failing to fopen()
>>  - xdiff-interface.c: report errno on failure to stat() or fopen()
>>  - wt-status.c: report error on failure to fopen()
>>  - server-info: report error on failure to fopen()
>>  - sequencer.c: report error on failure to fopen()
>>  - rerere.c: report correct errno
>>  - rerere.c: report error on failure to fopen()
>>  - remote.c: report error on failure to fopen()
>>  - commit.c: report error on failure to fopen() the graft file
>>  - log: fix memory leak in open_next_file()
>>  - log: report errno on failure to fopen() a file
>>  - blame: report error on open if graft_file is a directory
>>  - bisect: report on fopen() error
>>  - ident.c: use fopen_or_warn()
>>  - attr.c: use fopen_or_warn()
>>  - wrapper.c: add fopen_or_warn()
>>  - wrapper.c: add warn_on_fopen_errors()
>>  - config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, too
>>  - config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD
>>  - clone: use xfopen() instead of fopen()
>>  - Use xfopen() in more places
>>  - git_fopen: fix a sparse 'not declared' warning
>>
>>  We often try to open a file for reading whose existence is
>>  optional, and silently ignore errors from open/fopen; report such
>>  errors if they are not due to missing files.
>
> If anyone wants to continue this, I've cleaned up the series based on
> Johannes comments here [1]. It does not have the Darwin change though.

Also it seems to be missing the SUPPRESS_FOPEN_REDEF thing by
Ramsay.  I'll mix these two in, post to the list for review and
requeue.

Thanks.


> There was the last question about the '*' test change in ref path and
> what exact code change causes that, which I can't answer because I
> don't have Windows, or the time to simulate and pinpoint the fault on
> Linux.
>
> [1] https://github.com/pclouds/git/commits/fopen-or-warn

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

[Duy Nguyen]

On Mon, May 22, 2017 at 1:11 PM, Junio C Hamano  wrote:
> * nd/fopen-errors (2017-05-09) 23 commits
>  - t1308: add a test case on open a config directory
>  - config.c: handle error on failing to fopen()
>  - xdiff-interface.c: report errno on failure to stat() or fopen()
>  - wt-status.c: report error on failure to fopen()
>  - server-info: report error on failure to fopen()
>  - sequencer.c: report error on failure to fopen()
>  - rerere.c: report correct errno
>  - rerere.c: report error on failure to fopen()
>  - remote.c: report error on failure to fopen()
>  - commit.c: report error on failure to fopen() the graft file
>  - log: fix memory leak in open_next_file()
>  - log: report errno on failure to fopen() a file
>  - blame: report error on open if graft_file is a directory
>  - bisect: report on fopen() error
>  - ident.c: use fopen_or_warn()
>  - attr.c: use fopen_or_warn()
>  - wrapper.c: add fopen_or_warn()
>  - wrapper.c: add warn_on_fopen_errors()
>  - config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, too
>  - config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD
>  - clone: use xfopen() instead of fopen()
>  - Use xfopen() in more places
>  - git_fopen: fix a sparse 'not declared' warning
>
>  We often try to open a file for reading whose existence is
>  optional, and silently ignore errors from open/fopen; report such
>  errors if they are not due to missing files.

If anyone wants to continue this, I've cleaned up the series based on
Johannes comments here [1]. It does not have the Darwin change though.
There was the last question about the '*' test change in ref path and
what exact code change causes that, which I can't answer because I
don't have Windows, or the time to simulate and pinpoint the fault on
Linux.

[1] https://github.com/pclouds/git/commits/fopen-or-warn
-- 
Duy

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

[Junio C Hamano]

Jonathan Nieder  writes:

> Junio C Hamano wrote:
>> Jonathan Nieder  writes:
>>> Junio C Hamano wrote:
>
 * bw/forking-and-threading (2017-05-15) 14 commits
> [...]
  The "run-command" API implementation has been made more robust
  against dead-locking in a threaded environment.

  Will merge to 'next'.
>>>
>>> What's holding this up?  The deadlock it fixed was a real,
>>> non-theoretical issue.
>>
>> Does "Being down-sick over the weekend" count?
>
> Yes.  Sorry, I should have asked in a more productive way.
>
> I applied the patches locally to ensure tests continue to pass
> reproducibly but was worried because the patches had been ejected from
> "next" and had been in "Will merge" state for the last couple of
> pushes.

There also is "which ones should go first to 'master'".  Regression
fixes want to go earlier than fixes to age-old issues, for example.

In any case, today was my "move them to 'next'" day (I aim to have
approximately 2 such days a week), so quite a few things will now be
in 'next' when today's integration cycle finishes.

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

[Jonathan Nieder]

Junio C Hamano wrote:
> Jonathan Nieder  writes:
>> Junio C Hamano wrote:

>>> * bw/forking-and-threading (2017-05-15) 14 commits
[...]
>>>  The "run-command" API implementation has been made more robust
>>>  against dead-locking in a threaded environment.
>>>
>>>  Will merge to 'next'.
>>
>> What's holding this up?  The deadlock it fixed was a real,
>> non-theoretical issue.
>
> Does "Being down-sick over the weekend" count?

Yes.  Sorry, I should have asked in a more productive way.

I applied the patches locally to ensure tests continue to pass
reproducibly but was worried because the patches had been ejected from
"next" and had been in "Will merge" state for the last couple of
pushes.

Your health is more important.  I hope you get well soon.  Sorry
again, and thanks for looking them over.  

Sincerely,
Jonathan

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

[Junio C Hamano]

Jonathan Nieder  writes:

> Junio C Hamano wrote:
>
>> * bw/forking-and-threading (2017-05-15) 14 commits
>>  - usage.c: drop set_error_handle()
>>  - run-command: restrict PATH search to executable files
>>  - run-command: expose is_executable function
>>  - run-command: block signals between fork and execve
>>  - run-command: add note about forking and threading
>>  - run-command: handle dup2 and close errors in child
>>  - run-command: eliminate calls to error handling functions in child
>>  - run-command: don't die in child when duping /dev/null
>>  - run-command: prepare child environment before forking
>>  - string-list: add string_list_remove function
>>  - run-command: use the async-signal-safe execv instead of execvp
>>  - run-command: prepare command before forking
>>  - t0061: run_command executes scripts without a #! line
>>  - t5550: use write_script to generate post-update hook
>>
>>  The "run-command" API implementation has been made more robust
>>  against dead-locking in a threaded environment.
>>
>>  Will merge to 'next'.
>
> What's holding this up?  The deadlock it fixed was a real,
> non-theoretical issue.

Does "Being down-sick over the weekend" count?

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

[Jonathan Nieder]

Hi,

Junio C Hamano wrote:

> * bw/forking-and-threading (2017-05-15) 14 commits
>  - usage.c: drop set_error_handle()
>  - run-command: restrict PATH search to executable files
>  - run-command: expose is_executable function
>  - run-command: block signals between fork and execve
>  - run-command: add note about forking and threading
>  - run-command: handle dup2 and close errors in child
>  - run-command: eliminate calls to error handling functions in child
>  - run-command: don't die in child when duping /dev/null
>  - run-command: prepare child environment before forking
>  - string-list: add string_list_remove function
>  - run-command: use the async-signal-safe execv instead of execvp
>  - run-command: prepare command before forking
>  - t0061: run_command executes scripts without a #! line
>  - t5550: use write_script to generate post-update hook
>
>  The "run-command" API implementation has been made more robust
>  against dead-locking in a threaded environment.
>
>  Will merge to 'next'.

What's holding this up?  The deadlock it fixed was a real,
non-theoretical issue.

Thanks,
Jonathan