milke / GitFinder-Issues

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

Not handling nested repos correctly #99

Closed jiiq closed 3 years ago

jiiq commented 3 years ago

In the nested repo, gitfinder thought it's in the enclosing repo.

milke commented 3 years ago

@lifenxiang, is the nested repo a submodule of the enclosing repo?

jiiq commented 3 years ago

@milke, no, just another ordinary repo.

@lifenxiang, is the nested repo a submodule of the enclosing repo?

milke commented 3 years ago

Hey @lifenxiang, may I ask why did you close this?

I admit I haven't dedicated it much attention yet, as I was on a holiday (sort of) and also busy with other things, but I wanted to take a look at it. I have to admit I haven't really encountered similar situations before (a repository nested inside another repository, but not being its submodule) and I don't really know how core git CLI and other git clients handle such situation.

jiiq commented 3 years ago

Hi @milke, as far as know, git searches upwards from current dir, the first .git found is considered the current repo. I just don't want the issue being open while being no progress. I can reopen it if you want.

iocouto commented 3 years ago

Git will usually look at the current working directory for .git, and if it can’t find it, will try the parent directory. There are, therefore, a variety of situations where simply ‘nesting’ repositories inside each other may cause surprising and unexpected results - and that is not the “recommended git way” of doing this.

If you have a project that uses/requires/depends on external libraries and frameworks, and you want to manage those dependencies yourself directly with git, you should use submodules. That is the “official” git way of ‘embedding’ a repository’s files inside another.

But while submodules can be handy, keeping track of nested dependencies manually can get very complicated, very quickly. That is why there are many tools nowadays that do that automatically for us - such an npm for frontend packages, composer for php, etc. These ‘package managers’ can resolve complex dependency trees, pinpoint conflicts, warn about deprecated or abandoned projects, and maintain our packages updated automatically. Most of them will automatically use git behind the scenes, but provide us with an easier interface for handling those package dependency issues.

So, while putting a git repository inside another ‘may work’ in some situations, it’s definitely not recommended practice. If your project is super simple, and the sub-projects it depends on are also your own, you may want to look at submodules. For everything else, you should probably be looking at a dedicated package and dependency manager for your programming language.