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

Re: [RFC PATCH] merge-recursive: symlink's descendants not in way

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 17, 2019, 22:37 UTC
Message-ID
<xmqq8sqm7dmw.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20190917223236.149613-1-jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
Show 6 quoted lines
>> In any case, if the working tree has 'foo' as a symlink, Git should
>> not look at or get affected by what 'foo' points at.
>
> Git should not, but it does - there is a call in process_entry() that calls
> lstat() on "foo/bar", which indeed reports that "foo/bar" is a directory. This
> patch adds a check that none of its ancestors are symlinks.

Yeah, I recall having to add has_symlink_leading_path() long time ago in different codepaths (including "apply"). It is not surprising to see a similar glitch remaining in merge-recursive (it's a tricky issue, and it's a tricky code).

Previous: Jonathan TanNext: Jonathan Tan
Message 10 of 13 in “merge-recursive thinks symlink's child dirs are "real"”
  1. Jonathan TanSep 16, 2019
  2. SZEDER GáborSep 16, 2019
  3. Elijah NewrenSep 17, 2019
  4. Jonathan NiederSep 17, 2019
  5. Elijah NewrenSep 17, 2019
  6. Elijah NewrenSep 17, 2019
  7. merge-recursive: symlink's descendants not in wayJonathan Tan, Sep 17, 2019
  8. Junio C HamanoSep 17, 2019
  9. Jonathan TanSep 17, 2019
  10. Junio C HamanoSep 17, 2019
  11. Jonathan TanSep 17, 2019
  12. SZEDER GáborSep 17, 2019
  13. Elijah NewrenSep 18, 2019

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.