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
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/
Matheus TavaresRe: gitignore as symbolic link
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
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
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.
brian m. carlsonRe: gitignore as symbolic link
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
Re: gitignore as symbolic link
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.
Ævar Arnfjörð BjarmasonRe: gitignore as symbolic link
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.