dotfiles repo breaks repos in (ignored) subdirectories

[riggs]

I have a git repo in my home directory which I used to track various dot files. This repo has a .gitignore with one line, *, and I add files to be tracked directly.

I have most of my repos in ~/code/. I am unable to get gitfinder to recognize those repositories, either via adding them directly or adding the ~/code/ directory. gitfinder sees every file in ~ as under the purview of my dotfiles repo, not the more specific one.

The git CLI (& GitUp) behave as expected.

[milke]

So basically, your home directory ~/ is actually one "enclosing" repo, and then your "projects" repos are located in ~/code/, right? Can you please paste a screenshot of your "repo list" in GitFinder > Preferences > Repositories, like I did below?

Thanks.

[riggs]

While (most of) my project repos are in ~/code/, none of them are tracked by the repo located at ~/.

[milke]

Okay… So, considering the screenshot you posted, do you see any icon badges and can you invoke any git(finder) command from the contextual menu when you browse (in Finder) into ~/?

And, do you see any icon badges and can you invoke any git(finder) command from the contextual menu when you browse (in Finder) in ~/code/toyOS/?

Screenshots would be helpful, thanks.

[riggs]

Yes, gitfinder contextual menus all show up with reference the git repo at ~/ for every file & directory below it, including those actually managed by a by a different repo.

On Fri, Feb 10, 2023 at 6:15 PM Dragan Milić @.***> wrote:

Okay… So, considering the screenshot you posted, do you see any icon badges and can you invoke any git(finder) command from the contextual menu when you browse (in Finder) into ~/?

And, do you see any icon badges and can you invoke any git(finder) command from the contextual menu when you browse (in Finder) in ~/code/toyOS/?

Screenshots would be helpful, thanks.

— Reply to this email directly, view it on GitHub https://github.com/milke/GitFinder-Issues/issues/118#issuecomment-1426517789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEOUKHWGQKYJ6PHVYIYGQ3WW3KZNANCNFSM6AAAAAAUV3VKPI . You are receiving this because you authored the thread.Message ID: @.***>

[milke]

Hm, that's strange, because looking into your list of repos, GitFinder should not "look" into parent directories of ~/code/toyOS/ and ~/code/nirvamed-software/, hence it should not register eventual repo in ~/code/, or ~/. It'd be a different situation if, for example, your list contains ~/. Unless that /Volumes/Case_Sensitive leads to your ~/ though links or whatever…

Would it be possible to share settings of your repo at ~/ (.gitignore, config info/exclude files…)? I'd like to setup environment as similar as yours and try to reproduce the issue. Thanks.

[riggs]

I did initially add my home directory as a repo, hoping gitfinder would find and add the repos in the subdirectories appropriately, but I have since removed it. Is there some caching?

[riggs]

https://github.com/riggs/dotfiles

[milke]

I did initially add my home directory as a repo, hoping gitfinder would find and add the repos in the subdirectories appropriately, but I have since removed it. Is there some caching?

There's no caching, but FinderSync extensions are strange beasts and they're controlled by the macOS, not by the containing application. So please, try this:

• Quit GitFinder

• Open Activity Monitor application and look for processes containing e.g. gitf. Find any running GitFinderSync process(es) (like in the picture below) and force-quit it/them.

  

• Relaunch GitFinder

• Make sure instance(s) of GitFinderSync is/are started as well (like in the picture below).

  

  If you don't see any, execute in terminal:

killall Finder

and it/they should reappear.

Let me know if this perhaps solved the issue, that is, detected repos in ~/code/, but not the one in ~/.

BTW, you were right, when you add a directory into the repo list, GitFinder will find repos in subdirectories down the hierarchy. In your case, it's enough to add ~/code/, instead of adding each repo separately.

[riggs]

I removed the other directories I added, then added ~/code/, stopped gitfinder, relaunched Finder, then restarted gitfinder. Now the repos in subdirectories are showing up as appropriate, but gitfinder is repeatedly throwing this dialogue box, seemingly once for each repo it found in ~/code/.

[riggs]

Poking at it more, it seems the dialogue pops up every time I click on a directory in one of my repos...

I'll see if it persists after gitfinder has stopped re-indexing.

[milke]

No, it won't stop 🙁

Unfortunately, GitFinder isn't really suitable for your particular situation. I'll try to explain what happens and it's rooted in the way GitFinder discovers repositories. Now, this will be a VERY long post. Not only because I'll try my best to explain what happens and how GitFinder works (in a foreign language), but also with a hope you may come up with some suggestions about how to solve the problem. Your ideas may be smarter and make more sense than mine.

First of all, why does the list of repos exist? GitFinder is sandboxed and that list is needed to allow GitFinder to access added directories. Without that, access to directories/repos isn't allowed due to sandboxing. At the same time, that list also serves the purpose of which directories FinderSync extension GitFinderSync should monitor (the less monitored directories, the better performance in theory).

When you browse into a directory which is outside of all directories in the repo list (not in a hierarchy of any of those), nothing happens. But when you browse into any directory inside hierarchies of directories in the repo list, GitFinder checks if that directory is a root of some repo. If it is, GitFinder detects and "opens" that repo. Any further browsing into that directory or any subdirectory down its hierarchy will reference that "opened" repo. GitFinder will show icon badges and git commands for that repo.

If the browsed directory isn't the root of a repo, GitFinder moves up the directory hierarchy, checking if the next immediate parent is the root of a repo. And so on, up the directory hierarchy tree, until a directory out of GitFinder sandbox (or file system root) is reached.

Now, if the currently reached parent is out of GitFinder's sandbox and it is NOT the root of a repo, nothing happens, GitFinder aborts walking up the directory hierarchy tree. But if the reached directory is out of GitFinder's sandbox and it IS the root of a repo (like ~/ in your case) GItFinder throws that error dialogue, informing you "hey, I found a repo, but it's outside my sandbox, perhaps you want to include it in". And that happens every time such directory is encountered.

Now you probably understand why that error dialog appears every time you browse into your ~/code/directory; it isn't the root of a repo (its subdirectories are), but its immediate parent is the root of a repo and outside of the sandbox, hence the error dialog. And at the moment there's no option to ignore certain unreachable repos (like ~/ in your case) in a way of a checkbox saying something like "Do not show error for this repo again."

Of course, the obvious solution to all of the above is to add ~/ to the repo list, but then you have your initial problem; subrepos not recognized properly 🙁

About subrepos, there's another thing to note… Once GitFinder finds a certain repo with its root directory, all subdirectories will be ignored further, browsing into them will not trigger repo checking, it will immediately point to already "opened" repo in one of the parent directories (I hope you understand what I'm talking about here).

Let's take your example; you have a "parent" repo in ~/ and a lot of "subrepos" in ~/code/. You put ~/ in your repo list in GitFinder preferences. Let's say you're in the Finder's icon's view and at the moment GitFinder (and its extension GitFinderSync) start, you're positioned in e.g. ~/code/toyOS/src/. GitFinder will start checking for a repo in ~/code/toyOS/src/, going up the directory tree and find the repo in ~/code/toyOS/. Everything will work fine, you'll see that repo related icon badges and git commands.

But let's say, and which is much more likely, when GitFinder starts you're positioned in ~/, or any other subdirectory down its hierarchy (but not in ~/code/), in any view, as icons, list, columns… GitFinder will eventually find the repo in ~/ (because it is in your repo list, hence inside the sandbox). And it will start showing icon badges and git commands related to THAT "home" repo. Browsing into any of your repos in ~/code/ will automatically point to already discovered repo in ~/, because you browsed into the subdirectory of already "opened" repo, like explained in one of the paragraphs above.

One thing I can do is already mentioned checkbox "Do not show error for this repo again." for repos out of the sandbox. And the other thing would be NOT to ignore browsing into subrepos of already opened repo. But I did that because the core-git tool does the similar, with it's "hint" warning:

hint: You've added another git repository inside your current repository.
hint: Clones of the outer repository will not contain the contents of
hint: the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use:
hint: 
hint:   git submodule add <url> Bitvavo
hint: 
hint: If you added this path by mistake, you can remove it from the
hint: index with:
hint: 
hint:   git rm --cached Bitvavo
hint: 
hint: See "git help submodule" for more information.

It may be confusing which icon badges and commands to show; those of the parent repo, or of the subrepo.

At the end, just to mention that even making GitFinder not sandboxed wouldn't resolve this problem completely. It would solve the problem of this particular error dialog, but it wouldn't solve the problem of subrepos being ignored if a parent repo is already "opened".

I'm open to hear your suggestions. Currently, I'm leaning to do the following:

• Introduce "Do not show this error for this repo again." for repo-out-of-sandbox error.
• Not ignore subrepos inside already opened parent repo, with a hope it won't create some other problems, which I cannot envision at the moment.

Once again, sorry about this novel, but I hope it's helpful to understand how things currently work and to come up with best ideas of how to improve them.