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

Re: [PATCH v4 2/2] merge-recursive: fix the refresh logic in update_file_flags

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 19, 2020, 21:39 UTC
Message-ID
<xmqq36b6dzox.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<CABPp-BFH2qgM2oR-6g-3RgPegpq4yZujizxCb=_Ax0g2WFOYYw@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
Show 27 quoted lines
>> Hmph, !.call_depth would avoid resetting update_wd to 0, so the only
>> difference this patch makes is when the caller of this helper passed
>> (update_wd == 0) during the outermost merge.  We did not tell
>> add_cacheinfo() to refresh, and refresh_cache_entry() was not
>> called.  But the new code forces refresh to happen for normal
>> entries.  The proposed log message explains that a refresh is needed
>> for a new cache entry, but if I am reading the code correctly, this
>> function is called with !update_wd from two places, one of which is
>> the "Adding %s" /* do not overwrite ... */ the log message mentions.
>>
>> But the other one?  When both sides added identically, we do have an
>> up-to-date result on our side already, so shouldn't we avoid forcing
>> update_wd in that case?
>
> This change doesn't force update_wd (write out a new file, also
> implies refreshing is needed), this only forces refreshing (check
> stat-related fields of existing file).
>
>> I do not think passing refresh==1 in that case will produce an
>> incorrect result, but doesn't it force an unnecessary refreshing?
>>
>> Puzzled.
>
> It does force a refreshing, and it is a necessary one based on
> merge-recursive's design.  You can verify by putting an "exit 1" right
> ...
> So, this was a bug all along for BOTH cases, we just didn't notice before.

Ah, thanks. It was just me getting a wrong impression from the proposed log message that only the other one needed refresh; if both sides need a refresh, then the change is absolutely correct.

Thanks for clearing my puzzlement.  Will queue.
Previous: Elijah NewrenNext: Elijah Newren via GitGitGadget
Message 19 of 20 in “t3424: new rebase testcase documenting a stat-dirty-like failure”
  1. t3424: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 17, 2020
  2. Elijah NewrenFeb 17, 2020
  3. Phillip WoodFeb 18, 2020
  4. Elijah NewrenFeb 18, 2020
  5. Phillip WoodFeb 19, 2020
  6. Elijah NewrenFeb 19, 2020
  7. Junio C HamanoFeb 19, 2020
  8. Phillip WoodFeb 19, 2020
  9. Johannes SchindelinFeb 18, 2020
  10. Elijah NewrenFeb 18, 2020
  11. t3424: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 18, 2020
  12. Junio C HamanoFeb 18, 2020
  13. Elijah NewrenFeb 18, 2020
  14. t3433: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 18, 2020
  15. 0/2 t3433: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 19, 2020
  16. 2/2 merge-recursive: fix the refresh logic in update_file_flagsElijah Newren via GitGitGadget, Feb 19, 2020
  17. Junio C HamanoFeb 19, 2020
  18. Elijah NewrenFeb 19, 2020
  19. Junio C HamanoFeb 19, 2020
  20. 1/2 t3433: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 19, 2020

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.