Github: Git integration doesn't work if .git/ not in top level

[move[bot]]

@alexwhitman commented on May 13, 2014, 8:40 AM UTC:

If the .git/ directory isn't in the top level directory then git integration doesn't work:

This issue was moved by rsese from atom/atom#2203.

[move[bot]]

@dcunited08 commented on May 15, 2014, 6:44 PM UTC:

That would be great functionality to have.

[move[bot]]

@pritambaral commented on May 16, 2014, 12:06 PM UTC:

What would be the performance cost if we looked for gitroot on each "directory open" rather than "project init" as is the case now. Since we only need to look at immediate children, not recursively, I don't think it would be too much.

[move[bot]]

@geddski commented on Oct 21, 2014, 2:59 AM UTC:

Would love for it to pick up the parent directory's .gitignore when opening a sub folder in atom.

[move[bot]]

@lee-dohm commented on Oct 21, 2014, 8:54 AM UTC:

Actually, isn't this essentially just asking for a special case of "Multiple folder support" #770? If so, this is a duplicate.

[move[bot]]

@alexwhitman commented on Oct 21, 2014, 9:06 AM UTC:

That depends on how multiple folder support is anticipated to work. If each folder is expected to have .git/ at the first level then it's a separate issue. However, if .git/ can be at any level within any folder then that would solve this issue as well.

[move[bot]]

@piranna commented on Oct 21, 2014, 9:08 AM UTC:

I think is in fact just the oposite, to be able to open Atom in an internal folder of a git repository and that Atom show the files status.

[move[bot]]

@yn5 commented on Oct 30, 2014, 8:52 AM UTC:

Multiple git repositories in one project: big +1 for me

[move[bot]]

@LordGaav commented on Nov 14, 2014, 11:25 AM UTC:

Would also love to see this 👍

[move[bot]]

@briandavidson commented on Dec 11, 2014, 3:27 AM UTC:

+1.

Also.. the lack of this functionality has led me to another issue: Opening a folder in a new window via right-clicking a folder in the file tree pane is hit or miss. Most of the time it just opens a new window at the same folder level as my current atom window.

[move[bot]]

@oktayacikalin commented on Feb 4, 2015, 9:06 AM UTC:

+1

[move[bot]]

@lexicalunit commented on Feb 20, 2015, 6:27 PM UTC:

👍 would use this feature every day!

[move[bot]]

@h-svab commented on Feb 25, 2015, 4:03 PM UTC:

+1

[move[bot]]

@LordGaav commented on Mar 13, 2015, 11:34 AM UTC:

I can currently work around this issue when opening multiple root folders in one Atom window. Git works normally because the .git folder is in the root. I also use the project-manager plugin with a small patch to easily re-open a set of root folders in a window.

[move[bot]]

@wjwwood commented on Mar 17, 2015, 2:13 AM UTC:

+1 this is also something that I miss from SublimeText's VCS Gutter plugin.

Actually, isn't this essentially just asking for a special case of "Multiple folder support" #770? If so, this is a duplicate.

I don't think so. What you've suggested might be a workaround, but I often want to open a single folder which contains a hierarchy of folders, some of which are git repositories.

What would be the performance cost if we looked for gitroot on each "directory open" rather than "project init" as is the case now. Since we only need to look at immediate children, not recursively, I don't think it would be too much.

If I understand your suggesting correctly I think that it would not work for this:

├── bar
│   └── bar1_git_repo
└── foo
    ├── foo1_git_repo
    └── foo2_git_repo

[move[bot]]

@jtheoof commented on May 26, 2015, 6:06 PM UTC:

👍 Running into atom/tree-view#375 because of my project folder is a subdirectory of the git root.

[move[bot]]

@msom commented on May 27, 2015, 12:22 PM UTC:

+1

[move[bot]]

@polybuildr commented on Jun 3, 2015, 9:48 AM UTC:

+1

[move[bot]]

@jarig commented on Jun 6, 2015, 8:31 PM UTC:

Modified tree-view to support nested git repos, though I'm not 100% familiar with Atom code, so maybe this approach has some flaws or side-effects. Maybe Atom experts can advise.

[move[bot]]

@mauricioszabo commented on Jun 8, 2015, 8:12 PM UTC:

I, for example, have made a lot of custom configurations on my Atom Init script to be able to commit and see diffs from multiple GIT repositores, mostly because I work with Atom in lots of projects that use GIT submodules. So, in my case, .git is in the root folder, but in some subfolders I have symlinks to other git repositories, or even submodules so default git implementation doesn't work correctly for me.

I, for one, can't 👍 enough

[move[bot]]

@jarig commented on Jun 10, 2015, 2:05 AM UTC:

A bit improved atom/tree-view#469, added configurable refresh of nested repos to be able adjust performance based on needs.

In work example:

[move[bot]]

@Zireael07 commented on Jun 10, 2015, 7:02 AM UTC:

Woo!

[move[bot]]

@acontreras89 commented on Jun 18, 2015, 6:52 PM UTC:

👍

[move[bot]]

@ruffsl commented on Aug 7, 2015, 10:59 PM UTC:

+1

[move[bot]]

@ownagedj commented on Aug 31, 2015, 7:03 AM UTC:

👍 would be really great to have this feature in atom

[move[bot]]

@esteban-diaz commented on Sep 17, 2015, 2:28 PM UTC:

yes please

[move[bot]]

@bretonics commented on Sep 19, 2015, 2:58 AM UTC:

I would love to see this addressed. Any updates? Also, look at this behavior: Interestingly enough, so long as the lowest level directory is open first to it's parent, the repo is recognized and tracked. When removing the child project folder, the parent project does not display anymore.

[move[bot]]

@phord commented on Oct 1, 2015, 3:10 PM UTC:

I'm looking into this one, but the solution is quite involved and eventually affects several packages. I'm trying to implement a generic enough solution that each package can rely on it instead of using copy-pasted code as they do now.

I'm not a JS/CoffeeScript programmer normally, so the surprise-factor of JS operations is slowing me down. I think I'll get there, though.

I'm a little concerned that this bug has flowered into a discussion of several related but distinct bugs. I'll try to make it clear which issues are fixed as I progress.

Or maybe I am going in the wrong direction and jarig's solution is the right one. 😞

[move[bot]]

@phord commented on Oct 2, 2015, 10:31 PM UTC:

I created a script to investigate the various behaviors. It creates a directory structure like this:

folder/
   +---super/                    # a git repository with submodules
        +---bar/                 # a subdirectory containing files
        +---foo/
             +---submodule/      # a git submodule with a .git/ directory
             +---gitdir/         # a git submodule with a .git file (gitlink)
             +---other-project/  # a git project which is not a submodule

Each git repo in the tree contains an unchanged file, a changed file and an untracked file.

Here's what it looks like when I start Atom in different start folders of that tree (folder, super, bar, foo, gitdir, other-project, submodule):

(This might be different from what you see because I have some local changes I've been experimenting with. But it's close to the current situation.)

Problems:

1. When the project directory is folder
   
   
   
   • [ ] It does not recognize any of the git repos as repos under folder
   
   
   • [ ] It does not hide any of the metadata (.git dirs)
   
   
2. When the project directory is super
   
   
   
   • [x] It recognizes it as a repo and colors its files correctly
   
   
   • [x] It recognizes gitdir and submodule as submodules
   
   
   • [ ] It does not recognize other-project as a repo at all and does not track its changes
   
   
3. When the project directory is bar
   
   
   
   • [x] It recognizes it is in a repo and colors its files correctly
   
   
   • [x] It shows correct status colors for changed and untracked files inside foo relative to super
   
   
   • [ ] The top folder bar itself is not colored to show that it has changed files
   
   
4. When the project directory is foo
   
   
   
   • [x] It recognizes it is in a repo and colors its files correctly
   
   
   • [x] It recognizes submodules
   
   
   • [ ] It does not hide metadata. Weird.
   
   
   • [ ] It does not recognize other-project as a repo
   
   
   • [ ] It shows other-project's files as unchanged
   
   
   • [ ] The top folder 'foo' is not colored to show that 'foo' has changes
   
   
   • [x] It shows correct status colors for changed and untracked files inside foo relative to super
   
   
5. When the project directory is gitdir or submodule
   
   
   
   • [x] Each is recognized as a git repo
   
   
   • [ ] Each is not recognized as a submodule of some higher project
   
   
6. When the project directory is other-project
   
   
   
   • [x] It is recognized as a git repo
   
   
   • [x] Its files are colored correctly for the first time
   
   

Some of this behavior might be caused by my local changes. I'll investigate that later and update these notes. In particular, I am surprised by foo's metadata showing up and submodule's git-repo icon instead of a submodule icon.

Edit: Notice that these observations are all related to the tree-view package. Some of these may be caused by atom internals, but I suspect most are not. Fixes may be similar in different packages, but ultimately there will need to be fixes applied to many different packages. (e.g. atom/tree-view#488)

[move[bot]]

@bretonics commented on Oct 2, 2015, 10:54 PM UTC:

phord I really like what you did there. Well done. I hope you do find the solution as the behavior is interestingly odd.

[move[bot]]

@phord commented on Oct 5, 2015, 11:21 PM UTC:

Progress: phord/tree-view@repoForPathAsync (phord/tree-view@fad0086)

1. When the project directory is folder
   
   
   
   • [x] 🆕It recognizes git repos as repos under folder
   
   
   • [x] 🆕It hides the metadata (.git dirs)
   
   
2. When the project directory is super
   
   
   
   • [x] It recognizes it as a repo and colors its files correctly
   
   
   • [ ] 🐞 It no longer recognizes gitdir and submodule as submodules (known regression)
   
   
   • [x] 🆕It recognizes other-project as a repo tracks its changes
   
   
3. When the project directory is bar
   
   
   
   • [x] It recognizes it is in a repo and colors its files correctly
   
   
   • [x] It shows correct status colors for changed and untracked files inside foo relative to super
   
   
   • [ ] The top folder bar itself is not colored to show that it has changed files
   
   
4. When the project directory is foo
   
   
   
   • [x] It recognizes it is in a repo and colors its files correctly
   
   
   • [x] It recognizes submodules
   
   
   • [x] 🆕It hides metadata.
   
   
   • [x] 🆕It recognizes other-project as a repo
   
   
   • [x] 🆕It shows other-project's files' correct status
   
   
   • [ ] The top folder foo is not colored to show that foo has changes
   
   
   • [x] It shows correct status colors for changed and untracked files inside foo relative to super
   
   
5. When the project directory is gitdir or submodule
   
   
   
   • [x] Each is recognized as a git repo
   
   
   • [ ] Each is not recognized as a submodule of some higher project
   
   
6. When the project directory is other-project
   
   
   
   • [x] It is recognized as a git repo
   
   
   • [x] Its files are colored correctly
   
   

More issues:
🐞 This change significantly slows atom startup (5x to 50x) when tree-view has many files to show. I'm exploring ways to improve this.

[move[bot]]

@sneridagh commented on Nov 26, 2015, 10:14 AM UTC:

benogle Is this merged? If not, why it's closed?

[move[bot]]

@50Wliu commented on Nov 26, 2015, 4:26 PM UTC:

benogle Is this merged? If not, why it's closed?

Well, for starters, this is an issue, not a PR, so it can't be merged. It's also still open.

[move[bot]]

@nascimento commented on Dec 1, 2015, 5:15 PM UTC:

+1

[move[bot]]

@switchtrue commented on Dec 4, 2015, 10:26 AM UTC:

+1

[move[bot]]

@goyney commented on Dec 15, 2015, 8:22 PM UTC:

+1

[michalmiddleton]

+1

[nmat]

+1

[ian-bertolacci]

None of the moved comments are recent enough to indicate what the status on this is.
Is this issue being fixed or has it fallen by the wayside (as unsolved 5 year old issues often do)?

[TriMoon]

Would like this functionality to work also :heart_eyes:
/ping @phord

[jrial]

It's far from workable yet.

I have some projects with git subrepos inside. When I change a file inside the git subrepo, it will colour the file and all parent paths up to the root to indicate the change. It will also correctly indicate the changes to the file in the gutter, so you can see what has been added/removed/changed. So at least there's that.

But when selecting/opening files in subrepos, the Git tab goes empty and prompts me to create a repository. This means I'm unable to interact with this subrepo in any meaningful way, as I need to drop to the shell to perform basic Git operations. See screenshot:

For comparison, here's what it looks like when I have a file open that's in the parent git repo:

[jaimemunera]

any updates on this issue?

[lee-dohm]

No, there are no updates on this issue.

On Sun, Feb 10, 2019 at 4:28 PM Jaime Munera [e-mail]
wrote:

any updates on this issue?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/atom/github/issues/1835#issuecomment-462196151, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA_XKQh9RMd-O8yQMJsj4LyiV7dy-eVEks5vMLktgaJpZM4ZMQiA
.

[cryobry]

I think that https://github.com/atom/atom/issues/19548 could be implemented independently of .git subfolders.

[aviatesk]

@rsese
Well, what's the status of this issue ??

I think github package already solved this issue, and not sure what are the remaining issues.

As for git-diff package, the related issues were posted a while ago, and now GitRepository.open (more precisely, https://github.com/atom/git-utils#gitopenpath-search--true) seems to be able to solve this issue easily.

[rsese]

The status is still the same as Lee mentioned a few comments up, there are no updates on the issue.

I think github package already solved this issue

Not sure what you mean? If you have a Git project in a directory project and that directory is contained in directory myProjects, if you open myProjects in Atom and then open some file from project, the Git tab will say "Create Repository", the line diffs don't show, the tree-view won't show git file statuses, etc.

[aviatesk]

@rsese
Ah I misunderstand what this thread is all about.

I meant github package can work for files in projects that are not added to project folders but git-diff package doesn't.

For example, if we have the directory structure like below:

Example project structure

├─ project 1 (Added to project folders)
│  ├─ .git
│  ├─ file 1
│  ├─ ...
│  ...
│
(somewhere else)
│
├─ project 2 (Not added to project folders )
   ├─ .git 2
   ├─ file 2
   ...
   ├─ project 3
      ├─ .git 3
      ├─ file 3
   ...

and we added project 1 to project folders and didn't add project 2.
Then github package would work for both file 1 and file 2, but git-diff would does only work for file 1 but not for file 2 (and of course not for file 3).
(This is what I proposed to fix in #19584)

I'm not sure ".git not in top level" issue would be applied to this case, since this is all about the files _outside of_ current projects.

The fix would actually be easy since we can just use the .git that would first appear when we move up from a targeted file when we only want to render its diff (e.g.: We can just use .git 2 for file 2 and .git 3 for file 3 and to search .git 2 from file 2 or .git 3 from file 3 would be easy with GitRepository.open API).
And I think the fix gonna be valuable even if it comes with this ".git not in top level", because it would be more than nothing.

[jarig]

Current problem can be fixed with this PR: https://github.com/atom/tree-view/pull/469

I've just recently rebased on the latest master and made it fully-green, so it should be good to go.
Personally use it everyday with more than 200+ nested repositories.

Made a release from my fork for those who can try it out:
https://github.com/jarig/tree-view/releases/tag/0.228.0-jarig

[lee-dohm]

The problem isn't the happy path cases, it's all the failure mode cases. Only one example of which is the .git in the home directory problem. If a solution that is being proposed solves this and doesn't cause problems for all of the ways that a git repository can be mis-configured, then please show us all of the test cases that you've generated to verify the findings.

[aviatesk]

@rsese
Could you give me what do you think about this comment ? https://github.com/atom/github/issues/1835#issuecomment-504753845
Sorry for hurrying you up, but I really want to fix this.

[lee-dohm]

@aviatesk As I pointed out in my comment above, the happy path cases are not what we're worried about. We have had numerous problems with the "just find the first .git folder above the given path" algorithm in the past (see my link above). So, no, we would not be interested in accepting your proposed change to Atom's behavior.

[jarig]

We have had numerous problems with the "just find the first .git folder above the given path"

Current algorithm is not just find ".git folder above", it also respects project boundaries and won't go further.
So if you've .git folder in home directory nothing bad will happen (all your projects won't be recognized as Git ones).

[aviatesk]

@lee-dohm I see. I understand this issue should be carefully fixed from the deep root of it.

---

FYI: @\here
In order to satisfy my current daily needs, I've just created this package, that is supposed to be an alternative to the default Git-Diff:
https://atom.io/packages/git-diff-plus

This includes a lot of enhancements/refactors of it, like showing diffs for files outside of current projects.

Of course this doesn't have the complete solution to this problem at all, but still this package works very fine for common cases, and thus I'm grad if you guys find this useful too !

[TriMoon]

@aviatesk , i was just about to try it out until i saw you mention Atom-IDE-UI which is dead...

[aviatesk]

@TriMoon The package just works even if you've not installed Atom-IDE-UI. It just means Atom-IDE-UI exports gutter element as well and the git-diff package bundled within Atom itself by default can collide with it and my git-diff-plus solves that as well.

[utkarshgupta137]

I've raised 3 PRs to fix this issue:
https://github.com/atom/atom/pull/21631
https://github.com/atom/tree-view/pull/1367
https://github.com/atom/tabs/pull/560

In addition, I've also got it fixed in other packages:
https://github.com/steelbrain/linter/pull/1715
https://github.com/atom-minimap/minimap-git-diff/pull/31
https://github.com/file-icons/atom-fs/pull/9

The fix is quiet simple, at least for my use cases: Use atom.project.repositoryForDirectory instead of comparing current path with added project folders. I need to write tests for them but haven't found the time. I've been using atom with those changes for over a month now without issues.
If there are any other packages with similar issues, let me know.
cc: @aviatesk

@lee-dohm @rsese Will the issues/edge-cases you guys mention occur with atom.project.repositoryForDirectory?