Don't treat git submodule as a project root

[thomasf]

1. Don't treat linked git repositories such as submodules as project roots. …
   The difference is that there is only a file named .git and not a directory.
   I do belive that this is the most common thing one would want.
2. Always treat all scm repository meta directories as irrelevant.
   This simplifies the generic type definitions.

[dgutov]

I do belive that this is the most common thing one would want.

I disagree with that decision.

[thomasf]

Hmm, ok. I agree that its a bit of a personal taste as a result of how the projects you work on are configured.
So it becomes a matter of defaults rather than one-setting fits-all.
For most medium sized projects i work on i would definitely want this change but for some larger ones it's maybe too much.

The idea is that a sub module usually is a part of an enclosing project and because of this should be treated like an "eproject".

Could you elaborate your disagreement?

[dgutov]

Yeah, depends on the use case. I'm thinking of the situation where submodules are external dependencies, "bundled" for convenience. You don't jump between them and the main project's files too often.

[dgutov]

So, since the user can override this, I don't think it's worth changing the default.

[thomasf]

I usually get annoyed when i "find file in project" of an submodule for reference and then from that file do another "find file in project" and don't get my projects files..

One feature I have been thinking about which kind of relates to this is to be able to set an default eproject amongs all open projects ant that all subsequent eproject-related calls only respond to the default project. I haven't looked into the consequences or implementation details of such a feature yet.

[dgutov]

I, on the other hand, hate doing eproject-grep and seeing irrelevant files. Well, maybe changing the default would be a reasonable thing to do: adding a new type of project is easier than modifying an existing one.

Considering some types of projects as special should be quite doable, though the implementation would be different depending on whether @jrockway pulls or rejects #32.

[thomasf]

I see.. Yet another alternative would be a customize-option to always consider the outermost currently open project as the actual project root. This way the actual project definitions would not be affected.

[thomasf]

Closing my reqest, not that important as it is mostly a matter of taste anyway.