gitignore as symbolic link

gitignore as symbolic link

[Justus Ranvier]

I have several repositories where the top level .gitignore file is a 
symbolic link to the actual file which is contained in a submodule which 
all the repositories share.

This worked fine up to and including version 2.31.1 but as of 2.32.0 
running any command which would cause .gitignore to be read results in a 
"too many levels of symbolic links error" and git behaves as if 
.gitignore is not present.

Re: gitignore as symbolic link

[Rene Kita]

On Thu, Oct 21, 2021 at 05:07:44PM -0800, Justus Ranvier wrote:
> I have several repositories where the top level .gitignore file is a
> symbolic link to the actual file which is contained in a submodule which all
> the repositories share.
> 
> This worked fine up to and including version 2.31.1 but as of 2.32.0 running
> any command which would cause .gitignore to be read results in a "too many
> levels of symbolic links error" and git behaves as if .gitignore is not
> present.
> 
This was fixed in commit a185dd58ecc17f2ea16985d59c9bb7b09bec7775 [1].

[1] https://lore.kernel.org/git/xmqqlf83h2a7.fsf@gitster.g/

Re: gitignore as symbolic link

[Matheus Tavares]

On Fri, Oct 22, 2021 at 1:57 PM Rene Kita <mail@rkta.de> wrote:
>
> On Thu, Oct 21, 2021 at 05:07:44PM -0800, Justus Ranvier wrote:
> > I have several repositories where the top level .gitignore file is a
> > symbolic link to the actual file which is contained in a submodule which all
> > the repositories share.
> >
> > This worked fine up to and including version 2.31.1 but as of 2.32.0 running
> > any command which would cause .gitignore to be read results in a "too many
> > levels of symbolic links error" and git behaves as if .gitignore is not
> > present.
> >
> This was fixed in commit a185dd58ecc17f2ea16985d59c9bb7b09bec7775 [1].

Hmm, the behavior Justus described is actually related to another
change. Since v2.32.0, git no longer follows ".gitattributes",
".gitignore" and ".mailmap" if they are symbolic links. It does that
by open()-ing these files with the O_NOFOLLOW flag, which returns
ELOOP ("too many levels of symbolic links error") when the basename is
a symlink. So the behavior you experienced is actually not a bug, but
an intended change.

For a full explanation please see a2ef579e261 ("attr: do not respect
symlinks for in-tree .gitattributes", 2021-02-16) [2] and feb9b7792f
("exclude: do not respect symlinks for in-tree .gitignore",
2021-02-16) [3].

But the short version is: git accesses these files either from the
working tree or the object store (think, e.g. a bare repo). Git never
follows symlinks in the second case, so following them on the working
tree was an inconsistent behavior which was fixed. (This also has a
security implication, in the sense that it could be dangerous to
follow symlinks that lead to paths outside the repository.)

Note that "core.excludesFile" and "$GIT_DIR/info/exclude" are still
allowed to be symlinks.

[2]: https://github.com/git/git/commit/2ef579e261
[3]: https://github.com/git/git/commit/feb9b7792f

> [1] https://lore.kernel.org/git/xmqqlf83h2a7.fsf@gitster.g/

Re: gitignore as symbolic link

[Justus Ranvier]

On 10/22/21 14:40, Matheus Tavares wrote:
> So the behavior you experienced is actually not a bug, but
> an intended change.

So it's a permanent loss of functionality that I just have to live with. 
Got it.

Re: gitignore as symbolic link

[Justus Ranvier]

Suppose a person is managing N repositories. Would that person prefer to 
maintain the list of files to ignore for every random IDE that anybody 
who joins the team might want to use in:

a: One place
b: N places


On 10/22/21 14:40, Matheus Tavares wrote:
> Note that "core.excludesFile" and "$GIT_DIR/info/exclude" are still
> allowed to be symlinks.

These are settings that are specific to each developer, right?

If I have N repositories with M developers and I need to add a new 
ignore pattern that's either and O(M) or an O(N) job, neither of which 
is significantly better than the other and both of which suck compared 
to the O(1) functionality that we had before when we could put the list 
on a shared submodule.

Re: gitignore as symbolic link

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On 2021-10-22 at 23:55:16, Justus Ranvier wrote:
> Suppose a person is managing N repositories. Would that person prefer to
> maintain the list of files to ignore for every random IDE that anybody who
> joins the team might want to use in:
> 
> a: One place
> b: N places

Developers should be responsible for ensuring that their own editor's
temporary files are ignored.  For example, I use Vim, so it's my
responsibility to ensure that I globally ignore swap files using
"core.excludesFile" or that my editor is configured not to produce them.
(In my case, it's the latter.)

As you point out, it's unsustainable to have to manage a list of the
detritus of every possible editor.  What if I had decided to use an
editor that is not very popular, like ae, joe, or acme?  Should every
project be responsible for dealing with my uncommon editor, or should I
be responsible for my own editing hygiene?
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: gitignore as symbolic link

[Justus Ranvier]

On 10/23/21 04:01, brian m. carlson wrote:
> For example, I

I'm glad that works for you and whatever organizations you happen to be 
involved in. I'm sure you're happy that git taking away this capability 
did not impact your workflow.

Other people have different use cases and operate under different sets 
of constraints and are considerably inconvenienced when functionality 
that has worked for many years is suddenly removed from a core piece of 
software like git.

Re: gitignore as symbolic link

[Ævar Arnfjörð Bjarmason]

On Sat, Oct 23 2021, Justus Ranvier wrote:

> On 10/23/21 04:01, brian m. carlson wrote:
>> For example, I
>
> I'm glad that works for you and whatever organizations you happen to
> be involved in. I'm sure you're happy that git taking away this
> capability did not impact your workflow.
>
> Other people have different use cases and operate under different sets
> of constraints and are considerably inconvenienced when functionality 
> that has worked for many years is suddenly removed from a core piece
> of software like git.

I've workd on repos that had the union of every editor tempfile under
the sun in the .gitignore, it didn't really cause any practical
problems, they tend not to conflict with "real" filenames.

As for the .gitignore problem I think it's very much in the state of
"patches welcome", see a previous summary of mine at :
https://lore.kernel.org/git/87o8c34dq6.fsf@evledraar.gmail.com/

I.e. I don't think anyone should consider the current behavior to be set
in stone, and certainly not when it comes to potential opt-in
configuration.