Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Johannes Schindelin]

Hi Junio,

On Sat, 3 Jun 2017, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > On Fri, 2 Jun 2017, Junio C Hamano wrote:
> >
> >> Samuel Lijin  writes:
> >> 
> >> >> What is holding this topic up? Anything Ben or I can do to move this
> >> >> closer to `next` or even `master`?
> >> >
> >> > It's in `next` right now (3196d093d6).
> >> 
> >> Thanks for pinging and checking ;-)  
> >> 
> >> I think the topic was merged to 'next' on the 23rd of last month and
> >> graduated to 'master' in the past few days, together with other
> >> topics.
> >
> > Okay. I never saw any "Will merge to" message, so I got worried.
> 
> Well, I cannot quite help if you are not reading them ;-)

Well, I cannot quite help when I am expected to read long "What's cooking"
mails with out-of-context information as opposed to replies to the threads
discussing the actual patch series.

:-P

I understand that it would be hard on you if I expected you to untangle
your What's cooking discussions into the mail threads with the
corresponding patches, of course.

That just proves my point about mailing lists being an inadequate means to
perform code review...

> Issue #06 of May marked it to be merged to 'next':
> https://public-inbox.org/git/
> 
> Issue #07 of May marked it for 'master':
> https://public-inbox.org/git/
> 
> Issue #08 of May kept it (i.e. no issues discovered in the
> meantime):
> https://public-inbox.org/git/
> 
> Issue #01 of June reports it in 'master':
> https://public-inbox.org/git/

Thank you,
Dscho

Re: public inbox links, was: Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Eric Wong]

Stefan Beller  wrote:
> Today I learned again how public-inbox is awesome! Thanks Eric!

You're welcome :)

> * You can just copy the message ID INCLUDING the surrounding < >
>   and public inbox still just shows you the correct message. I had assumed
>   you would need to strip off the < > and I did so since.

Yeah, it's a fallback since it's probably a common mistake.
AFAIK, git-send-email also avoids redundantly adding '<>' and
only adds them if necessary.

> On Fri, Jun 2, 2017 at 5:26 PM, Junio C Hamano  wrote:

> > Issue #01 of June reports it in 'master':
> > https://public-inbox.org/git/
>
> * However with the < > unstripped, the awesomeness is limited:
>   Some tools (including my mail reader as well as public inbox itself[1])
>   do not recognize the link when there are < > in there.

Yeah, that's actually bad form on Junio's part.  public-inbox
can only support it up to an extent...

I seem to recall seeing some standard or style recommendation
that URLs (of any type) be surrounded by angle brackets in text:



So public-inbox (and other parsers) should stop looking for URLs
outside of the '<>'

But I think the newer style manuals state having spaces around the
URL is enough.

> While the second point is not the end of the world, it's still
> slightly annoying,
> which is why I thought I'll point it out here.
> 
> [1] https://public-inbox.org/git/xmqqvaodx6g4@gitster.mtv.corp.google.com/

public inbox links, was: Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Stefan Beller]

On Fri, Jun 2, 2017 at 5:26 PM, Junio C Hamano  wrote:
>
> Issue #06 of May marked it to be merged to 'next':
> https://public-inbox.org/git/
>
> Issue #07 of May marked it for 'master':
> https://public-inbox.org/git/
>
> Issue #08 of May kept it (i.e. no issues discovered in the
> meantime):
> https://public-inbox.org/git/
>
> Issue #01 of June reports it in 'master':
> https://public-inbox.org/git/
>

Today I learned again how public-inbox is awesome! Thanks Eric!

* You can just copy the message ID INCLUDING the surrounding < >
  and public inbox still just shows you the correct message. I had assumed
  you would need to strip off the < > and I did so since.

* However with the < > unstripped, the awesomeness is limited:
  Some tools (including my mail reader as well as public inbox itself[1])
  do not recognize the link when there are < > in there.

While the second point is not the end of the world, it's still
slightly annoying,
which is why I thought I'll point it out here.

[1] https://public-inbox.org/git/xmqqvaodx6g4@gitster.mtv.corp.google.com/

Thanks,
Stefan

Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Junio C Hamano]

Johannes Schindelin  writes:

> Hi Junio,
>
> On Fri, 2 Jun 2017, Junio C Hamano wrote:
>
>> Samuel Lijin  writes:
>> 
>> >> What is holding this topic up? Anything Ben or I can do to move this
>> >> closer to `next` or even `master`?
>> >
>> > It's in `next` right now (3196d093d6).
>> 
>> Thanks for pinging and checking ;-)  
>> 
>> I think the topic was merged to 'next' on the 23rd of last month and
>> graduated to 'master' in the past few days, together with other
>> topics.
>
> Okay. I never saw any "Will merge to" message, so I got worried.

Well, I cannot quite help if you are not reading them ;-)

Issue #06 of May marked it to be merged to 'next':
https://public-inbox.org/git/

Issue #07 of May marked it for 'master':
https://public-inbox.org/git/

Issue #08 of May kept it (i.e. no issues discovered in the
meantime):
https://public-inbox.org/git/

Issue #01 of June reports it in 'master':
https://public-inbox.org/git/

Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Johannes Schindelin]

Hi Junio,

On Fri, 2 Jun 2017, Junio C Hamano wrote:

> Samuel Lijin  writes:
> 
> >> What is holding this topic up? Anything Ben or I can do to move this
> >> closer to `next` or even `master`?
> >
> > It's in `next` right now (3196d093d6).
> 
> Thanks for pinging and checking ;-)  
> 
> I think the topic was merged to 'next' on the 23rd of last month and
> graduated to 'master' in the past few days, together with other
> topics.

Okay. I never saw any "Will merge to" message, so I got worried.

Thanks,
Dscho

Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Junio C Hamano]

Samuel Lijin  writes:

>> What is holding this topic up? Anything Ben or I can do to move this
>> closer to `next` or even `master`?
>
> It's in `next` right now (3196d093d6).

Thanks for pinging and checking ;-)  

I think the topic was merged to 'next' on the 23rd of last month and
graduated to 'master' in the past few days, together with other
topics.

Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Junio C Hamano]

Johannes Sixt  writes:

>>   Waiting for an Ack to the SQUASH fix or a reroll of the tip commits.
>
> ACK!
>
> See also
> https://public-inbox.org/git/2899d715-a416-1852-4399-28af0a3e9...@kdbg.org/
>
> -- Hannes

Thanks.

Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Johannes Sixt]

Am 01.06.2017 um 09:44 schrieb Junio C Hamano:

* nd/fopen-errors (2017-05-30) 14 commits
  - mingw_fopen: report ENOENT for invalid file names
  - SQUASH??? use test_i18ngrep and add it at the end
  - mingw: verify that paths are not mistaken for remote nicknames
  - log: fix memory leak in open_next_file()
  - rerere.c: move error_errno() closer to the source system call
  - print errno when reporting a system call error
  - wrapper.c: make warn_on_inaccessible() static
  - wrapper.c: add and use fopen_or_warn()
  - wrapper.c: add and use 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.

  Waiting for an Ack to the SQUASH fix or a reroll of the tip commits.


ACK!

See also 
https://public-inbox.org/git/2899d715-a416-1852-4399-28af0a3e9...@kdbg.org/


-- Hannes

Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Samuel Lijin]

On Thu, Jun 1, 2017 at 2:56 PM, Johannes Schindelin
 wrote:
> Hi Junio,
>
> On Thu, 1 Jun 2017, Junio C Hamano wrote:
>
>> * dt/unpack-save-untracked-cache-extension (2017-05-20) 1 commit
>>   (merged to 'next' on 2017-05-23 at 3196d093d6)
>>  + unpack-trees: preserve index extensions
>>
>>  When "git checkout", "git merge", etc. manipulates the in-core
>>  index, various pieces of information in the index extensions are
>>  discarded from the original state, as it is usually not the case
>>  that they are kept up-to-date and in-sync with the operation on the
>>  main index.  The untracked cache extension is copied across these
>>  operations now, which would speed up "git status" (as long as the
>>  cache is properly invalidated).
>
> It was my understanding that Ben's analysis conclusively proved that the
> patch as well as the test are sound, and Dave agreed.
>
> What is holding this topic up? Anything Ben or I can do to move this
> closer to `next` or even `master`?

It's in `next` right now (3196d093d6).

> Ciao,
> Dscho

preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

[Johannes Schindelin]

Hi Junio,

On Thu, 1 Jun 2017, Junio C Hamano wrote:

> * dt/unpack-save-untracked-cache-extension (2017-05-20) 1 commit
>   (merged to 'next' on 2017-05-23 at 3196d093d6)
>  + unpack-trees: preserve index extensions
> 
>  When "git checkout", "git merge", etc. manipulates the in-core
>  index, various pieces of information in the index extensions are
>  discarded from the original state, as it is usually not the case
>  that they are kept up-to-date and in-sync with the operation on the
>  main index.  The untracked cache extension is copied across these
>  operations now, which would speed up "git status" (as long as the
>  cache is properly invalidated).

It was my understanding that Ben's analysis conclusively proved that the
patch as well as the test are sound, and Dave agreed.

What is holding this topic up? Anything Ben or I can do to move this
closer to `next` or even `master`?

Ciao,
Dscho

What's cooking in git.git (Jun 2017, #01; Thu, 1)

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

A bit more topics are now in 'master'.  We have some more fixes that
should be merged down soonish.

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

* dk/send-email-avoid-net-smtp-ssl-when-able (2017-05-20) 1 commit
  (merged to 'next' on 2017-05-23 at fc59b8a1d4)
 + send-email: Net::SMTP::SSL is obsolete, use only when necessary

 "git send-email" now uses Net::SMTP::SSL, which is obsolete, only
 when needed.  Recent versions of Net::SMTP can do TLS natively.

 This is somewhat broken; a fix will be merged to 'master' shortly.


* ab/conditional-config-with-symlinks (2017-05-17) 1 commit
  (merged to 'next' on 2017-05-23 at 616c2e)
 + config: match both symlink & realpath versions in IncludeIf.gitdir:*

 The recently introduced "[includeIf "gitdir:$dir"] path=..."
 mechansim has further been taught to take symlinks into account.
 The directory "$dir" specified in "gitdir:$dir" may be a symlink to
 a real location, not something that $(getcwd) may return.  In such
 a case, a realpath of "$dir" is compared with the real path of the
 current repository to determine if the contents from the named path
 should be included.


* ab/perf-wildmatch (2017-05-12) 2 commits
  (merged to 'next' on 2017-05-23 at 0adb7dac31)
 + perf: add test showing exponential growth in path globbing
 + perf: add function to setup a fresh test repo

 Add perf-test for wildmatch.


* bp/sub-process-convert-filter (2017-05-15) 11 commits
  (merged to 'next' on 2017-05-23 at 89f5420a82)
 + convert: update subprocess_read_status() to not die on EOF
 + sub-process: move sub-process functions into separate files
 + convert: rename reusable sub-process functions
 + convert: update generic functions to only use generic data structures
 + convert: separate generic structures and variables from the filter specific 
ones
 + convert: split start_multi_file_filter() into two separate functions
 + pkt-line: annotate packet_writel with LAST_ARG_MUST_BE_NULL
 + convert: move packet_write_line() into pkt-line as packet_writel()
 + pkt-line: add packet_read_line_gently()
 + pkt-line: fix packet_read_line() to handle len < 0 errors
 + convert: remove erroneous tests for errno == EPIPE

 Code from "conversion using external process" codepath has been
 extracted to a separate sub-process.[ch] module.


* bw/forking-and-threading (2017-05-15) 14 commits
  (merged to 'next' on 2017-05-23 at 79a6a59851)
 + 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.


* bw/pathspec-sans-the-index (2017-05-12) 6 commits
  (merged to 'next' on 2017-05-23 at 45c8ef3115)
 + pathspec: convert find_pathspecs_matching_against_index to take an index
 + pathspec: remove PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP
 + ls-files: prevent prune_cache from overeagerly pruning submodules
 + pathspec: remove PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE flag
 + submodule: add die_in_unpopulated_submodule function
 + pathspec: provide a more descriptive die message

 Simplify parse_pathspec() codepath and stop it from looking at the
 default in-core index.


* dt/unpack-save-untracked-cache-extension (2017-05-20) 1 commit
  (merged to 'next' on 2017-05-23 at 3196d093d6)
 + unpack-trees: preserve index extensions

 When "git checkout", "git merge", etc. manipulates the in-core
 index, various pieces of information in the index extensions are
 discarded from the original state, as it is usually not the case
 that they are kept up-to-date and in-sync with the operation on the
 main index.  The untracked cache extension is copied across these
 operations now, which would speed up "git status" (as long as the
 cache is properly invalidated).


* jc/name-rev-lw-tag (2017-03-29) 2 commits
  (merged to 'next' on 2017-05-23 at 3f88b6d73c)
 + name-rev: