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

[alexwhitman]

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

[dcunited08]

That would be great functionality to have.

[pritambaral]

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.

[geddski]

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

[lee-dohm]

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

[alexwhitman]

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.

[piranna]

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.

[yn5]

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

[LordGaav]

Would also love to see this :+1:

[briandavidson]

+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.

[oktayacikalin]

+1

[lexicalunit]

:+1: would use this feature every day!

[h-svab]

+1

[LordGaav]

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.

[wjwwood]

+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

[jtheoof]

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

[msom]

+1

[polybuildr]

+1

[jarig]

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.

[mauricioszabo]

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 :+1: enough

[jarig]

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

In work example:

[Zireael07]

Woo!

[acontreras89]

:+1:

[ruffsl]

+1

[ownagedj]

:+1: would be really great to have this feature in atom

[esteban-diaz]

yes please

[bretonics]

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.

[phord]

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. :disappointed:

[phord]

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)

[bretonics]

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

[phord]

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

1. When the project directory is folder
   
   
   
   • [x] :new:It recognizes git repos as repos under folder
   
   
   • [x] :new: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
   
   
   • [ ] :beetle: It no longer recognizes gitdir and submodule as submodules (known regression)
   
   
   • [x] :new: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] :new:It hides metadata.
   
   
   • [x] :new:It recognizes other-project as a repo
   
   
   • [x] :new: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:
:beetle: This change significantly slows atom startup (5x to 50x) when tree-view has many files to show. I'm exploring ways to improve this.

[sneridagh]

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

[50Wliu]

@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.

[nascimento]

+1

[switchtrue]

+1

[goyney]

+1

[franklinkim]

+1

[stepelu]

+1

[yoko]

+1

[mhedgpeth]

+1

[Algram]

Most anticipated feature for me personally. +1

[VitaliyR]

Same thing for me, +1

[gz]

+1

[sidguptajhs]

+1
I have to use SublimeText instead for most of my work because of this issue:(

[marcosalberto]

+1

[agalitsyn]

+1, I would like to use atom for golang dev, and it convenient to open GOPATH folder with all libs

[davetoxa]

+1

[samartioli]

+1

[nabeelomer]

+1

[Viveur]

+1

[tehOPEologist]

+1

[mwarkentin]

+1 for me as well - was quite surprised that this didn't work.. I thought the git integration was broken at first.

[DerToti]

+1

[thuandt]

+1
Please add this features to Atom Editor

[jurajkapsz]

+1

[MarkSpruijt]

+1

[PolygonFox]

+1

[semoog]

+1

[geddski]

Woah. I just manually told Atom to ignore the files that this would normally catch (node_modules, dist, built files, etc.) and now Atom is literally 10x faster for me. Atom used to constantly choke and show the "Reindexing Project" message all the time. The difference after adding this is night and day. I wonder if this is the root cause of many people's performance issues. This issue should probably get bumped up in priority.

@lee-dohm @50Wliu

[geddski]

For anyone else that wants to work around this, you can manually ignore file patterns in the settings:

[mwarkentin]

Looks like .git at least is ignored by default:

[robbieaverill]

+1 - this is pretty much the only thing that is holding me back from switching to Atom from Sublime

[bourdeau]

+1

[bretonics]

Any updates addressing this issue? A bit annoying, but I love my Atom ⚛....this fix would greatly improve my workflow.

[gilmatic]

👍

[drcmda]

+1 This is quite frustrating for us as we use folders containing multiple projects. The editor remains grey, without visual clues it becomes very hard to keep track of changes. This would be one of the most useful features for us.

[frensuren]

+1

[goyney]

This issue is literally 2 years old now. How has it not been addressed?

[rvzanten]

Still waiting for this to be fixed. Runing Atom 1.8.0

[gontadu]

No idea @goyney. I found this out the hard way!

[ayberkozgur]

+1 quite annoying if you have to work with projects with submodules all the time.

[Igloczek]

@lee-dohm Any updates? It's quite important thing in projects with at least some kind of modularity.

[dktn]

+1, very annoying.
In contrast Sublime Text's GitGutter works flawlessly with multiple repos, and without any performance hit.

[gamead]

really need this

[guilhermevrs]

+1

[phord]

Several people have fixed this on their own, including me. But the atom core switched to a completely different Git implementation since then, converted it all to async, and now has switched back. It's hard to fix quicksand.

One of Atom's central features -- Git integration -- suffers from the lack of commitment. It's a shame. The Git-related packages suffer from this waffling, too. It makes this editor continue to feel like an experiment.

Welcome to open-source, folks. Please help by sending patches.

[bretonics]

@phord Indeed what a shame, and the irony being that it's from GitHub. Really needs to be addressed.

[lee-dohm]

No, @xenithorb, it doesn't need nor deserve to be annoying. What you are seemingly trying to do is violate the Code of Conduct. If you continue, you will be banned from participation.

[lee-dohm]

@phord For context, we switched to a different Git implementation because it had benefits for performance, which is an oft-cited complaint about Atom as I'm sure you're aware. We switched back because it caused a number of bugs and side-effects. We didn't catch these bugs because we don't have the resources to come even close to exhaustively test across all the different combinations of configurations that people will use Atom in.

We understand and agree that it is painful for our package author community when we have to go back and forth like this. We don't like making mistakes. We do our best to acknowledge when we make them and work to do better next time.

You're right, a lot of what Atom is doing _is_ an experiment. In my opinion, all great software is an experiment. We are learning as we go. We are trying new things and attempting to push boundaries. Again, this means that sometimes we'll make mistakes. We don't want to. It is simply part of being human and part of the process of trying new things.

Thank you for the constructive criticism. We're trying to do better.

[xenithorb]

I can offer a band-aid to someone stumbling on this for the first time:

You can add multiple folders through ctrl+shift+o with shift+<select> at a time, and they show up as multiple projects.

It's not as neat and organized as the filesystem tree like it should be, but it works for the meantime.

[michalmiddleton]

+1

[pedrofracassi]

Would love to see this fixed. Its the only reason I haven't fully switched to Atom from Sublime.

[cmruffin]

+1. My use case is three interrelated repositories, with a global TAGS file. And symbols-view, git-diff, and git integration just work.

├── common
│   └── .git
├── edk2
│   └── .git
├── plaform
│   └── .git
└── TAGS

[chris-c-thomas]

+1 for this. Never realized it was an issue until I had a nested project structure and couldn't figure out why it wasn't recognizing the repo!

[pierrre]

+1 for this. Never realized it was an issue until I had a nested project structure and couldn't figure out why it wasn't recognizing the repo!

Thank you for this comment @chris-c-thomas
https://github.com/golang/go/wiki/NoMeToo

[qnub]

@pierrre for 3 years old bug? Think it just ignored like: "they used it for 3 years already as is — think this feature no so matter to waste time for it" So proposing add 👍 to comment is like attempt to ignore customer because no one counting it but each new comment leaved here during 3 years is pretty good visualisation of majority of this bug… IMO

So, i leave one more
👍
here :)

[yao23]

I'm in top folder and it works only after save (cmd+s) the change, then it will show in git.

[chriddyp]

Love this project ❤️
Getting around this issue for now by just doing

$ git init

in the project folder and then removing the .git folder when I need to use git.

[rapus95]

especially since git got integrated into atom it'd be pretty nice if there was some progress with this issue :/ i just can't imagine they made the git(hub) integration by default and forgot to resolve an issue that in fact makes a lot of the integration pretty much useless. especially since on the other hand they added support for always reopening the previous session (https://github.com/atom/atom/pull/13947) and thus encouraging having a lot of directories at the same time

[jiku]

For inspiration and reference, VSCode plans to add multi-root SCM this month.

(With multi-root, submodules and whatever else, maybe a tight-knit, overlaid integration with the existing tree/editor would be useful in addition to an SCM dock/pane and separate staging and diffing which both Atom and VSCode have opted for.)

[cbcoutinho]

A small update I just noticed related to this issue: If you have a directory open that contains git repositories, those repositories are not treated like repositories in atom:tree-view and elsewhere already mentioned in this thread. I added one of the git repositories as a project folder to the tree-view along with my 'main' directory, and _that too_ was not being handled like a git repository. Atom seems to know what's open and the same directory open in multiple places is an issue.

[ginkgomzd]

I want to up-vote this feature too.
It would prevent idiot's like me from missing out on great features of Atom:
https://github.com/atom/flight-manual.atom.io/issues/396

[babakgh]

👍

[blairjam]

It seems a little ridiculous that this is still an issue almost into 2018. Is there any sort of plan for fixing this?

[julianrutten]

@50Wliu so will this be resolved in the next release or any other update on the progress?

[chris-c-thomas]

Would also like to know about this being implemented soon or not...

[50Wliu]

@julianrutten @chris-c-thomas None of the Atom maintainers have made any progress on this issue. We're open to a PR adding nested repository support, but it'd need to be thoughtfully implemented and not have any negative performance impacts.

[fschoenfeldt]

i am not sure if im right here but since today, the "git panel" doesnt show any "progress" anymore, everything is greyed out. im kinda noob to git so some help would be appreciated :)

thanks in advance!

_edit: i guess it may have confused something like finding the "*,git" file or so. IDK._
_edit2: more detailed infos; i just do my everyday work and commit everything daily to have a waybackmachine_

[cbcoutinho]

@fschoenfeldt, it looks like you have a git repo at the top of the tree
view, so it isn't related to this issue. I'd recommend creating a new issue
at the atom/github integration project

Cheers

On Dec 19, 2017 18:10, "fschoenfeldt" [e-mail] wrote:

i am not sure if im right here but since today, the "git panel" doesnt show
any "progress" anymore, everything is greyed out. im kinda noob to git so
some help would be appreciated :)
[image: unbenannt]
https://user-images.githubusercontent.com/4721311/34169421-a819318e-e4e7-11e7-9eaa-f015ccb231e1.PNG

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/2203#issuecomment-352823903, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMTd7KQ8t8FFSPZ-oIdHEX-MHll2tJtQks5tB-3tgaJpZM4B6XHx
.

[fschoenfeldt]

well, i hoped to have quick support here but yes. thank you.

Chris Coutinho [e-mail] schrieb am Di., 19. Dez. 2017 um
18:14 Uhr:

@fschoenfeldt, it looks like you have a git repo at the top of the tree
view, so it isn't related to this issue. I'd recommend creating a new issue
at the atom/github integration project

Cheers

On Dec 19, 2017 18:10, "fschoenfeldt" [e-mail] wrote:

i am not sure if im right here but since today, the "git panel" doesnt show
any "progress" anymore, everything is greyed out. im kinda noob to git so
some help would be appreciated :)
[image: unbenannt]
<
https://user-images.githubusercontent.com/4721311/34169421-a819318e-e4e7-11e7-9eaa-f015ccb231e1.PNG
>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/2203#issuecomment-352823903, or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AMTd7KQ8t8FFSPZ-oIdHEX-MHll2tJtQks5tB-3tgaJpZM4B6XHx
>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/2203#issuecomment-352825024, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgKnyNAfM0RPuPMe422iQgKtMjJfoWzks5tB-7kgaJpZM4B6XHx
.

[jebby]

I would love to have this implemented. I prefer to have my git repositories neatly nested inside a parent folder. It doesn't make sense that I should have to open the individual git project outside of that parent folder and clutter up my sidebar more than need be.

Don't get me wrong, The git integration in Atom is awesome, but I think I'll be sticking with using git on command line until I am able to at least toggle something in the settings that allows me to track changes to git repositories stored in a sub-project folder.

[qnub]

And Go language even use it as main conception — to have many VCS in single workspace! https://golang.org/doc/code.html#Overview :

A workspace contains many version control repositories (managed by Git, for example).

So usually you will use go folder as single workspace for all your go projects each of it will have own git repo.

[isavl]

+1

[Astrofin]

For what it's worth, I think there's a pretty easy workaround for this. I'd been trying to get this working by opening the parent directory that had all my projects in it, but that does not work because there is no .git folder in that parent directory. It does work, however, if I open one of the project folders that is contained in the parent directory, then individually open each other project folder in that directory with the "Add Project Folder..." function in the editor. For example, let's say I have this folder structure:

├── my-first-project
│   └── .git
├── my-second-project
│   └── .git
├── my-third-project
│   └── .git

What I was doing before that did not work was opening the projects folder. What I did that does work was individually open each of my-first-project, my-second-project, and my-third-project. It is a bit of a pain to open each project folder like that, but Atom will remember your recent projects so I think it's pretty manageable once you've opened them. And then this actually works, so there's that.

http://blog.atom.io/2015/04/15/multi-folder-projects.html

[wjwwood]

@Astrofin that might work for some users, but take my use case for example, I have 52 git repositories in a folder with a hierarchy of subfolders. Adding each of them in turn doesn't really scale for me, and also I loose the hierarchy which organizes them. Being able to browse the available repositories by category and dive into them quickly is paramount to my productivity. Also it's necessary to sometimes remove repositories and add new ones depending on the situation, so maintaining a project file with all of them added as separate folders is not something I want to do and I see it as completely unnecessary.

While I appreciate you pointing out the workaround, it's been something I was aware of since originally posting here three years ago (https://github.com/atom/atom/issues/2203#issuecomment-82036684), and is still not satisfactory enough to address my needs. For this reason I'm still on Sublime Text, and still wish I could switch to atom.

I've actually looked into contributing this feature myself, but the level to which git and a single git repository per project folder is integrated into atom is high. I don't feel this can be addressed without design changes and input from core members of the atom team.

[ruffsl]

For the simple scenarios like with the projects directory structure described by @Astrofin , I've simply been launching atom with a wildcard to avoid tediously adding each subfolder through the UI, e.g.:

cd projects
atom *

I suppose one could just a well write an alias script that recursively appends git repo directories nested and passes it as arguments to atom command at launch, but that doesn't solve the nested view issues like diff events in atom's file tree view, and the flattened view still breaks the structural hierarchy that is paramount to productivity traversing complex projects as @wjwwood described.

[jnsc]

Using a *, or adding sub-folders to workspace is only working for small to medium projects. Mine with a lot of sub folders just freeze the editor forever.

[bretonics]

This is literally so old, literally (issue opened on May 13, 2014), that the fact that it still doesn't work....is getting frustratingly old.

Feels completely forgotten, without even knowing if it's truly being addressed/considered by the core developers (will respectfully assume yes), even though its clear many users.

So, is there any planned roadmap?

[ginkgomzd]

I used to think this was an important feature.
I now don't think it is.
Why not have a separate atom window for each repo? Are you really working with git in that many repos simultaneously?

So many IDE's are bloated. I appreciate the stripped-down experience of Atom.
Use your desktop as your IDE.

You can probably find other helpers out there for working with git sub-repos.
Here is my quick and dirty bash function (put it in aliases or profile).
Execute any git command on all repos found below your current directory.

gitsubs() {
  gitsubs_max_depth=12

  echo searching for git repos
  echo directory max-depth = $gitsubs_max_depth
  echo executing git $@
( # use a subshell and change the field-separator
  # to allow for spaces in filenames
  IFS=$'\n'
  for d in `find . -maxdepth $gitsubs_max_depth -type d`
  do
    pushd $d >/dev/null;
#   if directory contains a .git dir OR if is a bare-repo:
    if [[ -d .git || $d == *.git && $(basename $d) != .git ]]; then
      echo ".,.,.,.,.   \\><((((*> [  $d  ] <*))))></    "; echo
      git $@;
      echo ""
    fi
    popd &>/dev/null
  done
)
}

[wjwwood]

@ginkgomzd I appreciate your perspective, but the fundamental constraint here which is one git repository per folder in the project is, in my opinion, unnecessary. I'm sure the designers had a reason for it, but there is a clear counter example in Sublime Text which provides git integration as plugins only and does not have this constraint, i.e. I don't need a more complex IDE to address this issue, but rather a more flexible text editor.

I could try to work around this issue, but again, I don't feel I should have to do so. Also, a shell script to workaround this shortcoming is fine, but I'm regularly switching between Windows and Linux/macOS and again I don't want to have to have tooling around the editor to make up for that problem.

Why not have a separate atom window for each repo?

Mostly because I have too many repos to have a window for each open all the time, and opening a file in an already open window is much faster than opening a new window for a project that I didn't have open yet.

Are you really working with git in that many repos simultaneously?

It might be an unusual use case (which is why I guess this hasn't gotten much attention), but yes, I regularly work with 50+ repositories simultaneously.

[arma26]

I'm also working on several projects that have easily over 50 nested repos. I work a lot with Puppet, the current best practice is to use r10k supplied with a Puppetfile which is basically a list of repo urls. The tool manages the entire collection as one codebase, checking out matching branches in each repo if one exists else using a default branch.

Any given task can span multiple repos that need to be treated as one logical change, and I've held off using any type of git integration in atom as it doesn't come anywhere close to fitting that use case. This is a necessary feature.

[flyingchipmunk]

You can include me as a developer that works with projects with >50 repos on a daily basis. This issue is one of my biggest holdouts from switching from Sublime honestly.

Besides the group of us who have specific large repo cases, here's a more wide spread audience example - think ansible roles. One repo per ansible role, and that list of repos grows very fast.

[dirk-thomas]

Just as a side note for anyone interested: this works flawlessly in Visual Studio Code :no_mouth:

[chris-c-thomas]

Hey with MS buying GitHub maybe we'll get a combined Atom and VS Code type editor.

Sent from my iPhone

On Jun 4, 2018, at 2:50 PM, Dirk Thomas [e-mail] wrote:

Just as a side note for anyone interested: this works flawlessly in Visual Studio Code 😶

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bretonics]

Interesting how right after the MS announcement, VS Code is suddenly suggested when this issue has been open for over 4 years.

[cryobry]

I don't know if this issue has been reported, but I use nested git repos within a parent git repo. I use the parent git repo to move all of my sites to my webserver, and the nested git repos to merge updates to the underlying templates from their upstream developers. I don't care about having git control over the nested repos in Atom, since I rarely sync them. However, I am not able to even sync the parent repo unless I am editing a file in the top-level directory. So for some reason, Atom is unaware of the nested git repos, yet aware enough to ignore them as simple file objects in the parent repo! Are there any workarounds for this?

[rsese]

/move to atom/github

[wjwwood]

@rsese in case you weren't aware, there's a new GitHub feature (still in beta) which allows you to transfer issues more cleanly (within the same organization), see: https://help.github.com/articles/transferring-an-issue-to-another-repository/

[rsese]

Yes, apologies all for the notifications flood 😦 I'm so used to using move bot for new issues that it totally slipped my mind about the number of notifications that would go out here and that feature would have behaved better. Going to go ahead and manually close this since it's now being tracked in https://github.com/atom/github/issues/1835 if folks want to subscribe (looks like move bot probably got rate limited so not everyone was pinged into the new issue).

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!