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

Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes

From
Duy Nguyen <pclouds@gmail.com>
Date
Nov 10, 2016, 11:00 UTC
Message-ID
<CACsJy8BJkV+0wbrYuVrwixfbnOKw0DrwLHEtH-fzOHtEHyiXBw@mail.gmail.com>
In-Reply-To
<20161110002335.z2z2stjtzgspikxe@sigill.intra.peff.net>
On Thu, Nov 10, 2016 at 7:23 AM, Jeff King <peff@peff.net> wrote:
Show 17 quoted lines
> On Wed, Nov 09, 2016 at 04:18:29PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
>> >
>> > I'm slightly confused. Did you mean "supporting any in-tree symlink to
>> > an out-of-tree destination" in your first sentence?
>>
>> I was trying to say that these "control files used solely by git"
>> have no business being a symbolic link pointing at anywhere, even
>> inside the same tree; actually, especially if it is inside the same
>> tree.
>
> OK. That is what my patch does (modulo .gitmodules, which I did not
> think of). But I think that is the opposite of Duy's opinion, as his
> review seemed to object to that.

I only objected the rationale (to be consistent with reading index). If you sold it as malicious symlinks, or even put it like Junio "no, the design makes more sense to be this way", I would be ok.

On the implementation side, we should print something friendlier than strerror(ELOOP) if we decide that "symlinks on .git* files are wrong". The standard ELOOP message does not communicate our design decision well to the users. But this is a minor thing and can be ignored.

Show 5 quoted lines
> As you know my ulterior motive is dealing with malicious out-of-tree
> symlinks, and I would be happy to deal with that directly. That still
> leaves symlinked ".gitmodules" etc in a funny state (they work in the
> filesystem but not in the index), but since nobody is _complaining_,
> it's a bug we could leave for another day.

The discussion trailed off a bit to symlinks in general in worktree too, I think. But it's not my itch, we can leave it for another day.

-- 
Duy
Previous: Jeff KingNext: Jeff King
Message 19 of 22 in “disallow symlinks for .gitignore and .gitattributes”
  1. 0/5 disallow symlinks for .gitignore and .gitattributesJeff King, Nov 2, 2016
  2. 1/5 add open_nofollow() helperJeff King, Nov 2, 2016
  3. 2/5 attr: convert "macro_ok" into a flags fieldJeff King, Nov 2, 2016
  4. 3/5 exclude: convert "check_index" into a flags fieldJeff King, Nov 2, 2016
  5. 4/5 attr: do not respect symlinks for in-tree .gitattributesJeff King, Nov 2, 2016
  6. Duy NguyenNov 7, 2016
  7. Jeff KingNov 7, 2016
  8. Jeff KingNov 7, 2016
  9. Duy NguyenNov 8, 2016
  10. Jeff KingNov 8, 2016
  11. Duy NguyenNov 9, 2016
  12. Jeff KingNov 9, 2016
  13. Junio C HamanoNov 9, 2016
  14. Jeff KingNov 9, 2016
  15. Junio C HamanoNov 9, 2016
  16. Jeff KingNov 9, 2016
  17. Junio C HamanoNov 10, 2016
  18. Jeff KingNov 10, 2016
  19. Duy NguyenNov 10, 2016
  20. 5/5 exclude: do not respect symlinks for in-tree .gitignoreJeff King, Nov 2, 2016
  21. Stefan BellerNov 2, 2016
  22. Jeff KingNov 2, 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.