gogit throws error while cloning repo with symlink

[shilpaworld]

gogit throws error while cloning repo with symlink. I am able to clone it locally with git commands, however go-git clone repository does not clone and gives error as symlink <file/link path> file exists

[mbohy]

@shilpaworld do you have a way to reproduce? We have this issue too, but it actually doesn't happen on clone, but rather on checkout. For us the sequence is:

• main branch has a directory at the top-level of the repo
• foo branch replaces that directory with a symlink to another directory (but the symlink has the same name as the original directory)
• go-git can clone the repo fine, with the main branch
• when I try to use go-git to checkout the foo branch, it fails with the symlink error you reference

I've tried to reproduce this with a simple example repo, but it doesn't happen there. I can reproduce it on an internal repo of our company, and I've been trying to debug it there.

From stepping through the code against the simple repo that doesn't reproduce, I can see that the checkout code diffs the worktree against the index and gets an array of "changes" to apply to the working directory. In the simple repo case, we process a deletion of the original repo, followed by the creation of the symlink, so it works fine. In the "real" repo, there are thousands of changes in this branch switch, so it's difficult to see the exact sequence, but I suspect that the "create symlink" change is being handled before the "delete directory" change, so we fail to create the symlink (as the directory that the symlink is supposed to replace is still there).

This makes me wonder if there is any "order" to the changes applied in a branch switch. If not, you could imagine other cases where doing things in the "wrong" order can cause problems -- for example, if we replace a directory with a file of the same name, I assume that would fail if we process the file creation first, before the directory deletion.

[mbohy]

After further debugging, our issue is actually unrelated to symlinks. Our real issue is that we are replacing a directory with a symlink (of the same name as the directory), and go-git's Reset doesn't properly remove the directory before attempting to create the symlink. See #670.