Re: Using .gitignore symbolic links?

On Thu, Jun 17 2021, Tessa L. H. Lovelace wrote:

The recent release candidate of Git (v2.32.0) hit my OS this week, and
it included a line () on symbolic links for several specific files are 
now ignored.

Thank you for putting the changelogs in an accessible location,
knowing that this was a known breaking change was useful in debugging
why my workflows stopped working.

I have two concerns.

First, the error thrown is

quoted

"warning: unable to access '.gitignore': Too many levels of symbolic

  links",

,,,which does not accurately represent what is happening.

I spent a bit of time convinced that I'd broken something with the
symbolic links during setup, and an error such as "symbolic linking no 
longer allowed for 'filename'." would make more sense, given the
change under discussion eliminates *any* use of symbolic links.


Secondly, and more personally important to me, a system administrator:
My repositories use symbolic links to allow a single .gitignore file
to define my folder structure, allowing me to avoid hardcoding the 
repo-specific folder paths into my configs.

Is there a flag to disable this new behavior?

If not, this change means I need to update dozens of files, duplicates
all, or completely rewrite my .gitignore files to have shyteloads of 
arbitrary file paths in them, which I'd rather not do.

Also, is there a justification for forcing this as the on-update
default new behavior, when a user-querying behavior (such as with 'git 
pull' defaults as they've changed recently) exists?

[CC-ing Jeff]

Breaking this was intentional, see https://github.com/git/git/commit/2ef579e261

That doesn't mean we can't take it back.

As discussed by Robert's reply and in that commit there's the workaround
of .git/info/exclude and the core.excludesFile.

However, we realize that sucks for many users. Let's say you have a
script to clone a "tree" of repositories similar to but not using
git-submodule (or they live side-by-side), such a thing won't Just Work
anymore.

At the end of the day there's an inherent conflict here between security
and convenience. We really want a repository to be safe to just "git
clone", i.e. we don't set up any hooks, execute code etc.; these
gitattributes and gitignore issues were on edges of that.

We can make it work as before, but it gets hard to distinguish the
gitignore you mean, from a gitignore that's pointing to /dev/urandom
(annoying), or to some crafted out-of-tree thing that'll cause an
overflow in the parser and an RCE.

Any way out of that that's configurable is going to be be the same
opt-in problem as core.excludesFile is now.

So I'd think our options are basically:

 1) Do nothing, it sucks for some people (like you) but we think it's worth it

 2) Some DWYM middle ground, e.g. we could discover if the link points
    to another git repo, and only trust it then, or if it's in the
    user's $HOME or whatever.

 3) Bring back the old behavior, it was more of a "while we're at it for
    gitattributes..." fix than something specifically a problem with
    gitignore, the RCE threat is a hypothetical, and we can more easily
    audit/be confident in the gitignore parser, probably...