support nested repos

[jarig]

Fixes atom/atom#2203

This patch works quite well even with >200 nested .git repos, though with some limitations:

1. If there are a lot of nested. git repos then start-up time might noticeably increase(with ~200 repos it was 10 sec). The reason is that GitRepository object seems to be not fully async while refreshing status.
2. Status refresh of GitRepositry objects on window_focus event is disabled, so if repos changed out of the Atom it might reflect wrong status (but there is extra Atom command for refreshing those).

[winstliu]

Looks like this can be unless relPath

[jarig]

unless triggers in case of 'undefined' as well, but in this case it should trigger only if string is empty(but not undefined).

[winstliu]

Right now Travis is reporting quite a few lint errors - you should fix those.

In addition, this will need specs before it can be considered for merging.

[jarig]

I've fixed all probs with existing specs and added 4 new ones (12 tests) covering all new functionality. Also created GIF showing what it is about

[wjwwood]

This works for me, but the diffs in the gutter of changed files doesn't seem to work anymore.

[jarig]

Rebased on latest changes.

This works for me, but the diffs in the gutter of changed files doesn't seem to work anymore.

Well yeah, that should be fixed on git-plus (or whatever plugin you use) side.
Instead of taking project root it should take the nearest upwards .git folder.

However git diffs with flat project structure should still work.

[ruffsl]

This is awesome

[winstliu]

Sorry, but it looks like there's more conflicts 😬.

[jarig]

Re-based again, with previous re-base accidentally took some extra files to commit(like packages.json), fixed that.

[mikekelly1]

@jarig Do modified files in sub-repositories show up when you press CTRL-T with your fix?

[jarig]

Do modified files in sub-repositories show up when you press CTRL-T with your fix?

Unfortunately not. Atom relies on the fact that there is only 1 GitProvider per project, but it should be changed to support multiple, then those providers can be updated from TreeView and in this way other things will work as well.

[phord]

@jarig fyi - I have a version (phord/tree-view@fad0086) that does manage to track modified file subscriptions successfully. But startup is slow. I'm working on improving it, though. Suggestions welcome.

[jarig]

@phord , @mikekelly1
I've made changes to support ctrl+t as well as highlighting of modified lines in files. Performance is quite good, tested with ~250 nested repos.
Tests are failing though, will check later why, in "real life" all works :)

[joshaber]

I'm not sure this is the right place for this fix. Ideally we'd make whatever changes are necessary in GitRepository or GitRepositoryAsync in Atom itself, so that all users of GitRepository* can take advantage of these fixes.

[omern1]

Why aren't you merging this?

[joshaber]

See my comment above: #469 (comment)

[watzon]

Definitely a feature that's needed. Can we get the ball rolling on this one?

[jarig]

I've rebased all changes again and fixed all tests and linting. So now it's fully green.

[Zireael07]

Hopefully this gets merged soon.

[lee-dohm]

Thanks for all the work that has been invested in this pull request.

In our weekly triage meeting, we discussed this change and have decided to not accept it. Besides the caveats mentioned at the top, we don't feel that this change has been validated against a wide enough variety of use cases to not have hidden pitfalls. And because there have been significant usability impacts around this functionality before, we can't take the risk of unleashing this untested on the entire user base.

Thanks again for the feedback and the work that you've put into this change.

[jarig]

And because there have been significant usability impacts around this functionality before

Is that real pitfall or theoretical? It never happened in real life, as current algo respects project boundaries.