Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

.git directory in the project tree after using FileSystem.resolve #10183

Closed
zaggino opened this issue Dec 16, 2014 · 8 comments · Fixed by #10304
Closed

.git directory in the project tree after using FileSystem.resolve #10183

zaggino opened this issue Dec 16, 2014 · 8 comments · Fixed by #10304

Comments

@zaggino
Copy link
Contributor

zaggino commented Dec 16, 2014

Since installing Brackets.Release.1.1.msi I keep seeing .git folder in my project tree, which wasn't there before (and shouldn't be as no-one should ever touch that directory manually). Core is linked to the latest master branch.
image

@cheesypoof
Copy link
Contributor

Are you sure this is not an extension issue @zaggino? As soon as I upgraded my brackets-git from 0.14.5 to 0.14.6 I noticed this as well. I am not using the new shell by the way.

@zaggino
Copy link
Contributor Author

zaggino commented Dec 16, 2014

There was this change which might have caused the issue: brackets-userland/brackets-git@d609a3a

But I don't think it should. I also noticed that if you do right click > refresh file tree .git directory disappears for a while and then pops back again.

I had to stop using brackets.fs so the Intel XDK which has different FileSystem implementation would continue to work with this extension. There should really be a way to resolve a file or directory without pushing the path to the index of file watching features.

@zaggino zaggino changed the title [CEF 2171] .git directory in the project tree .git directory in the project tree after using FileSystem.resolve Dec 16, 2014
@busykai
Copy link
Contributor

busykai commented Dec 16, 2014

I will take a look at it. I agree with @zaggino -- resolving an fs entry in the project should not impact the tree model. there's an exclusion list, but apparently it's not applied at all times or something. I'll root cause this and will get back.

@marcelgerber
Copy link
Contributor

@zaggino You shouldn't access .git via the FileSystem, that's what brackets-userland/brackets-git#436 is all about.

@zaggino
Copy link
Contributor Author

zaggino commented Dec 16, 2014

Forgot about that one @marcelgerber , thanks.
Then there's this one brackets-userland/brackets-git#853
I really need a way to check for .git with a proper API without the automatic indexing ... or at least be able to access index to remove it manually after check ...

@busykai
Copy link
Contributor

busykai commented Dec 16, 2014

there are two issues, i guess:

  1. we don't want to watch for fs events in auxiliary files (such .git). there's an API, actually, to at least unwatch an entry within a watched root, but it's private (for a reason). @marcelgerber, do you see the issue Accessing .git folder through Brackets file system adds it to the index and breaks Brackets brackets-userland/brackets-git#436 with the current version of brackets-git?
  2. the issue is this what this report describes: it seems like FileSystem.resolve() adds entry to ProjectModel even if it is, in theory, excluded.

@marcelgerber
Copy link
Contributor

Yeah, I see brackets-userland/brackets-git#436 again with brackets-git installed.
Luckily, a simple workaround is to add .git to the exclusion list.

@peterflynn
Copy link
Member

I left a very long comment in the PR with ideas about fixing, but one clarification on the discussion in this thread... Re @busykai's comment "there's an API, actually, to at least unwatch an entry within a watched root, but it's private (for a reason)": it's not actually possible on Mac or Win to unwatch a subset of a watched root. The native watching API we use watches an entire subtree with no ability to exclude parts of it. The private _unwatchEntry() API is only ever called on the watch root or on entries that have been deleted (for cleanup).

And even adding watches is very basic & limited right now: early on we talked about the public FileSystem.watch() supporting overlapping file tree regions, but that was never implemented. In theory we do support multiple non-overlapping watch roots, but then that has never really been tested :-) (So note, for example, that opened files from outside the project aren't currently watched, nor is the prefs JSON file).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants
@zaggino @redmunds @peterflynn @JeffryBooher @cheesypoof @marcelgerber @busykai and others