Re: [PATCH] git pull silently overwrites local directory with symlink due to .gitignore "dir/"

["brian m. carlson" <sandals@crustytoothpaste.net>]

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

On 2026-09-07 at 08:19:17, AIKSXD ax wrote:
> Hello,I would like to report a issue in Git that can cause silent data loss on user machines. The problem occurs when a '.gitignore' pattern ending with a slash (e.g. 'dir/') is used to ignore a directory, but a symbolic link with the same name will be committed. Later, when another user pulls the repository, Git silently replaces their local directory with that symlink, destroying all data inside it without any hints.
> 
> OS: Linux(Git 2.43.0) & Windows(Git 2.53.0.windows.2) both reproduced
> - The symlink is tracked and committed because the trailing-slash ignore rule have no effect on files.

Yes, as you've noticed, symlinks (and files) are not ignored by patterns
containing a trailing slash.  This is because `dataset/` doesn't
actually ignore `dataset`, but everything under it instead.  The index
doesn't track directories, only regular files and symlinks, so `dataset`
as a symlink is not even considered by that rule.

> - On pull, Git silently replaces the local directory with the symlink, causing irreversible data loss.
> This is unacceptable behavior; Git should never overwrite a local directory with a symlink without explicit user confirmation.

I tested this with a non-symlink file and Git also removes the directory
in this case.  As you noticed, `git checkout` deletes ignored files and
directories.  You can see in the manual page:

     --overwrite-ignore, --no-overwrite-ignore
         Silently overwrite ignored files when switching branches. This
         is the default behavior. Use --no-overwrite-ignore to abort the
         operation when the new branch contains ignored files.

Git does not consider ignored files to be valuable by default.  There
has been discussion of a `precious` attribute to preserve ignored files,
but it hasn't been implemented yet.  [0] is one relatively recent proposal.

> Impact:
> This issue can result in the loss of hundreds of gigabytes of local data, as users often keep large datasets or other important directories with the same name as an ignored symlink. The data loss is silent and occurs during a routine 'git pull'( I don’t know why so much free space showed up on my computer that day).
> 
> My options:
> The pattern 'dataset/' should also ignore a symlink with that name, so it never enters the repository in the first place.

This would be a substantial change in behaviour.  We don't know that the
symlink points to a directory and it would be bizarre to have a symlink
to a file affected in that way.  Moreover, on Unix, a symlink need not
actually point _anywhere_, so whether this worked would be dependent on
subtle behaviour about what the symlink is pointing to at this time.

> If such a symlink is committed (accidentally or otherwise), Git must detect the conflict when pulling to a machine that has a real directory at the same path, and refuse to overwrite it without prompting.

This would also be a big change in behaviour and probably break a lot of
tooling that relies on the status quo.

In general, I would recommend not keeping valuable data in untracked or
ignored files within the working tree.  I've seen lots of data loss from
this case and have actually had to restore people's development VMs from
a snapshot for that reason at a previous job.

[0] https://lore.kernel.org/git/pull.1627.git.1703643931314.gitgitgadget@gmail.com/
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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