milke / GitFinder-Issues

Bug and issue tracker for GitFinder - git client with macOS Finder integration
16 stars 1 forks source link

Too Many Redirects #53

Closed gegge87 closed 4 years ago

gegge87 commented 4 years ago

Schermata 2020-03-03 alle 17 48 42

Hello, I'm a noob trying to manage wikis of the many projects of my company massively.

  1. I created a main folder and then I cloned a repo (the only one set in the gitfinder preferences)
  2. The clone was made without a "packing" folder, but directly in the main, so I decided to undo and create a subfolder for the clone. I deleted the folder and I continued to see the repo syncing the changes, so I deleted the .git and all the hidden files too.
  3. Then every time i tried to do something the app crashed, so I deleted the app with a "full deleting" utility and reinstalled
  4. after reinstall I declared a repo folder, I created a subfolder and cloned the wiki repo in this folder, without success with an error ""path" exists and is not an empty directory"

I think someone has to explain me how, because I found no documentation

milke commented 4 years ago

Hi @gegge87, sorry for a bit delayed response.

First about cloning a repo… That error ""path" exists and is not an empty directory" means you're trying to clone a repo into a folder, which is not empty. If you don't see any file in it, even with options to see hidden files in Finder turned on, that most probably means there's that notorious .DS_Store file, which Finder doesn't show at all. You will have to delete it from the terminal, or just trash that folder and create a new one. It also doesn't help Finder can create that hidden file at any time, even right after you've created a fresh new folder, depending on your view type and other Finder options. And now hearing about the problem, I think GitFinder isn't helping in this situation either. So in the very next update I'll made GitFinder work like git command line tool, when it comes to repo cloning; you won't have to do Clone… from the contextual menu in the empty folder (which, like you've experienced, may not be empty at all), but it will create additional subfolder, naming it the same as the repo last path component, and then clone it into that new subfolder. So, to clarify:

currently, if you do Clone… a repo with the last path component of its URL being TestRepo.git in Finder in the folder ~/Documents/Repos**, GitFinder would clone that repo in exactly that folder (and require it to be empty).

in the future, if you do Clone… a repo with the last path component of its URL being TestRepo.git in Finder in the folder ~/Documents/Repos, GitFinder will create a subfolder ~/Documents/Repos/TestRepo (or Test Repo 2, Test Repo 3**, etc depending of name availability), make sure it's empty and then actually clone in that new subfolder.

Now, about the crash… So it seems you've cloned a repo, GitFinder started monitoring it, but then you decided to ditch it while GitFinder was running, you deleted it and deleted hidden .git folder, which made GitFinder crash, right? I'll repeat the same procedure and try to reproduce the crash, so that I can fix it. Thanks for reporting.

Finally, about that error too many redirects. That error comes from the underlying libgit2 library and it has nothing to do with any folder being empty or not. You used HTTP(S) method for cloning/authentication and this error means there were too many redirects from server you were trying to connect to and clone a repo from. Currently, GitFinder (libgit2 library actually) allows only redirects to the same host name and if number of redirect exceeds 7, it gives up the connection and reports the error, which screenshot you pasted above.

milke commented 4 years ago

Closing due to inactivity / no response.