git clean removes content of symlinks

[illuxio]

Hallo,

I'm using git version 2.7.0. I discovered recently that a git clean -xdfdeletes the content of my symlinks that are in my .gitignore file instead of removing the symlinks as in unix.

The symlinks was created by the command npm link.

I hop you will fix this soon.

[dscho]

The symlinks was created by the command npm link.

Please note that it is unreasonable to expect everybody to have npm installed (besides, you did not specify which npm. So you need to do a little homework and figure out what npm calls underneath, and come up with a Minimal, Complete & Verifiable Example.

I hop you will fix this soon.

I hope you realize that a statement like this is prone to cause the opposite of what you want. After all, who likes to be underappreciated and pushed around?

[illuxio]

As far as I understand npm uses junctions (can be created by mklink \J Link Target).

To reproduce the bug:

• create git repo with files
  • .gitignore
  • target/README.md
• Add /link to .gitignore
• Commit all files
• Execute in cmd.exe mklink \J link target to link the link and target
• Execute git clean -xdf

Now you will see that README.md is missing in target.

[rimrul]

EDIT: I messed this up. This comment and the next four are me accidentially leading this issue in the wrong direction.

• create git repo with files
• .gitignore
• target/README.md
• Add /link to .gitignore
• Commit all files
• Execute in cmd.exe mklink \J link target to link the link and target
• Execute git clean -xdf

Ummm... you have the folder target inside the repository, add the files inside it to the repository, and wonder that git clean -xdf doesn't ignore the folder? Does this only seem like the intended behaviour to me?

[illuxio]

I don't think so, because executing rm -rf link in the git bash or deleting the link in the explorer will not result in an empty target folder...

[rimrul]

I don't think so, because executing rm -rf link in the git bash or deleting the link in the explorer will not result in an empty target folder...

How about rm -rf target?

[illuxio]

Sure this will delete the target folder and the README.md, but this is not the point.
For me sound this like the question why git clean -xdf does not remove all file from the git repo.

My problem is that I have a folder "target" with files and obviously a junction "link" (a type of symlink) that links to this folder. Target and is files is wanted inside the repo and the junction "link" is not. Therefore, the the junction "link" is in the .gitignore file.

What I expected from git clean -xdf is that all wanted files style and all unwanted files are removed. This is not the case because "link" and all files inside "target" are removed.

[rimrul]

Sure this will delete the target folder and the README.md, but this is not the point.
For me sound this like the question why git clean -xdf does not remove all file from the git repo.

Sorry. I messed this up by not looking up, what exactly git clean -xdf is supposed to do...

Please accept my appology for wasting your time.

I can confirm that git clean -xdf doesn't touch the file on a Linux symlink.

[illuxio]

No problem. I think with my addition it is now more precise.

[whoisj]

so basically you want git clean -xdf to not follow junctions, but delete them unless they're ignored with a -e flag?

[illuxio]

Exactly.

J Wyman notifications@github.com schrieb am Mi., 20. Jan. 2016 19:19:

so basically you want git clean -xdf to not follow junctions, but delete
them unless they're ignored with a -e flag?

—
Reply to this email directly or view it on GitHub
#607 (comment)
.

[whoisj]

Exactly.

I implemented similar logic for Libgit2 some time ago. I can assist here as well, though I doubt I'd have time to generate a full pull request on the topic.

Win32's FindFirstFile/FindNextFile iterator structure returns enough information in WIN32_FIND_DATA to detect if a node is a reparse point or not ((fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)). From there a DeviceIoControl with FSCTL_DELETE_REPARSE_POINT should achieve what you want - the important piece is to detect the reparse point (aka Junction) and handle it as one.