Does not work for Github subfolder within project directory

[aurovrata]

I develop WordPress plugins and as such my porject directory is then entire WordPress root folder, which means that my github folder is acatually a sub-folder within the wp-content/plugins/ folder.

Is there anyway to get githb.atom.io package to work from a given sub-folder?

[smashwilson]

If you open and focus an editor for any file within your wp-content/plugins folder, the github package should find the correct repository. We find the "active repo" by walking up the directory tree looking for .git folders, just as git does.

[ericbiewener]

@smashwilson This doesn't appear to happen for me. I have a parent folder open that contains 3 subfolders, each of which have top-level .git directories. Atom doesn't recognize them.

[aurovrata]

doesn't seem to work, I am using linked folders to my github repo, as I use these repo files in several projects. Could this be the reason why it doesn't work?

[ericbiewener]

I don't think that's the issue. I'm not using symlinks and I have the same problem.

[smashwilson]

Oh, interesting. I can repro now too. Maybe we regressed on this at some point 🤔

[Ismail-elkorchi]

@smashwilson Any progress ? This must issue must be a priority, since every Wordpress developer who wish to benefit from ide-php features must set the project directory to the WordPress root folder as @aurovrata said.

See: atom/atom#2203

[Ismail-elkorchi]

cc @kuychaco @BinaryMuse @daviwil @50Wliu

[winstliu]

@BinaryMuse Does the github package use separate logic, or should this be closed as a duplicate of atom/atom#2203?

[Ismail-elkorchi]

@smashwilson Have you any idea about the future of this issue, and if it will get any attention soon ? If yes, can you please share it with the community ?

It seems that there is a lot of people who are desperately waiting for this feature : atom/atom#2203

[stevenzeck]

From what I can tell, only the top level folder is searched for a .git directory when adding a folder to the project. If I put a breakpoint in this function

github/lib/git-shell-out-strategy.js

Lines 343 to 356 in 3ab9dbe

	async resolveDotGitDir() {
	try {
	await fs.stat(this.workingDir); // fails if folder doesn't exist
	const output = await this.exec(['rev-parse', '--resolve-git-dir', path.join(this.workingDir, '.git')]);
	const dotGitDir = output.trim();
	if (path.isAbsolute(dotGitDir)) {
	return toNativePathSep(dotGitDir);
	} else {
	return toNativePathSep(path.resolve(path.join(this.workingDir, dotGitDir)));
	}
	} catch (e) {
	return null;
	}
	}

and open a single folder that contains three git directories, the only time it hits the breakpoint is when the this.workingDir is the top level one.

Consider this structure and I add Folder1 to my project workspace:

Folder1 (no .git folder, so state resolves to empty)
   folderA (has a .git folder, but never looked at)
   folderB (has a .git folder, but never looked at)
   folderC (has a .git folder, but never looked at)

[camlafit]

Hello

Looks related to #1835
Any evolves about this feature ? It's a bit ugly to add any subdirectory as a multiprojects

[lgeiger]

Oh, interesting. I can repro now too. Maybe we regressed on this at some point 🤔

@smashwilson Since you are able to reproduce this has there been any progress on this issue?

I started using git submodules heavily today and this makes it quite frustrating to use the github plugin which previously worked for me like a charm. It seams a lot of people are having this issue too (#1835).

Strangely enough, Atom recognizes submodules just fine, when the are also added as a top level folder:

[jrial]

It also seems to jumble up the contents of the .gitignore, applying the top-level .gitignore to subprojects. Not sure if that falls within this issue, or if I should open a separate one, so let me know if you'd like me to move this post to its own issue.

In the screenshot: the top-level project contains a .gitignore that hides settings_local.py (so we don't accidentally commit local configs). The subrepo "djangoconf" contains all configurations for our apps, and as such does not ignore that filename. However, I am unable to see settings_local.py when I expand the subrepo in the tree view.

[peterse]

I'm also having this issue. Any update would be appreciated

[FXschwartz]

I am having this issue as well. My project contains a parent directory and then multiple sub directories which are all their own repositories.

[gunsluo]

the same issue for me. my repo have a root go mod and multiple sub directories go mod file.

test repo: github.com/gunsluo/test2

run: GO111MODULE=on go get github.com/gunsluo/test2@v1.1.0. it works fine.

but run: GO111MODULE=on go get github.com/gunsluo/test2/log@v1.1.0
error message:

go get github.com/gunsluo/test2/log@v1.1.0: module github.com/gunsluo/test2@v1.1.0 found, but does not contain package github.com/gunsluo/test2/log

[utkarshgupta137]

I'm not able to reproduce this issue on Atom 1.53. If anyone can help me understand, I'll try to look into it. Here's what I understand the issue is/was:
Whenever there is a git repo, which is not a top-level folder, it doesn't get detected as repo properly. Further, if any parent folder/git repo contains .gitignore, it is also applied to submodules.

From my findings: This issue is present in many core packages and a few community packages. I've raised PRs for the ones I know about, see #1835 (comment).
But this issue has never actually affected the github package itself (i.e. git & github sidebars).

[utkarshgupta137]

@lgeiger the issue you're describing is with tree-view package not github package. As a temporary fix, please add all the actually git repos as project folders at the top of the stack. Then add any main folders you have. This case as well will be fixed through my PRs.

I think this issue can be closed in favour of #1835. cc: @smashwilson