git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/3] wt-status: implement opportunisitc index update correctly

From
Stefan Beller <sbeller@google.com>
Date
Dec 7, 2016, 22:06 UTC
Message-ID
<CAGZ79ka_Sh7jppCVkAhFWkXNffEg_SxUGN9VULseJBpQkDSyww@mail.gmail.com>
In-Reply-To
<xmqqmvg7wips.fsf@gitster.mtv.corp.google.com>
On Wed, Dec 7, 2016 at 1:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 28 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>> So my first question I had to answer was if we do the right thing here,
>> i.e. if we could just fail instead. But we want to continue and just
>> not write back the index, which is fine.
>>
>> So we do not have to guard refresh_cache, but just call
>> update_index_if_able conditionally.
>
> An explanation with stepping back a little bit may help.
>
> You may be asked to visit a repository of a friend, to which you do
> not have write access to but you can still read.  You may want to do
> "diff", "status" or "describe" there.
>
> In order to avoid getting fooled into thinking some paths are dirty
> only because the cached stat information does not match, these need
> to refresh the in-core index before doing their "comparison" to
> report which paths are different (in "diff"), what are the modified
> but not staged paths (in "status"), and if there is a need to add
> the "-dirty" suffix (in "describe").
>
> Since we are doing the expensive "bunch of lstat()" anyway, if we
> could write it back to the index, it would help future operations in
> the same repository--that is the reasoning behind the opportunistic
> updates.  It is perfectly OK if we do not have write access to the
> repository and cannot write update the index.
>

Thanks for that explanation! So I agree that we should not call it _if_needed, but the _if_able part is still confusing, as we check for different parts here.

The case of not being able to write (read only) sounds similar to the case of not being able to write (a concurrent lock), I'll think about it more.

Thanks, Stefan

Previous: Junio C HamanoNext: Paul Tan
Message 12 of 19 in “[BUG] Index.lock error message regression in git 2.11.0”
  1. Robbie IannucciDec 3, 2016
  2. Robbie IannucciDec 3, 2016
  3. Junio C HamanoDec 6, 2016
  4. Re* [BUG] Index.lock error message regression in git 2.11.0Junio C Hamano, Dec 6, 2016
  5. Junio C HamanoDec 7, 2016
  6. 0/3 Do not be totally silent upon lock errorJunio C Hamano, Dec 7, 2016
  7. 1/3 wt-status: implement opportunisitc index update correctlyJunio C Hamano, Dec 7, 2016
  8. Stefan BellerDec 7, 2016
  9. Junio C HamanoDec 7, 2016
  10. Stefan BellerDec 7, 2016
  11. Junio C HamanoDec 7, 2016
  12. Stefan BellerDec 7, 2016
  13. Paul TanDec 8, 2016
  14. Junio C HamanoDec 8, 2016
  15. 2/3 hold_locked_index(): align error handling with hold_lockfile_for_update()Junio C Hamano, Dec 7, 2016
  16. 3/3 lockfile: LOCK_REPORT_ON_ERRORJunio C Hamano, Dec 7, 2016
  17. Johannes SchindelinDec 8, 2016
  18. Robbie IannucciDec 8, 2016
  19. Junio C HamanoDec 8, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.