New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't treat git submodule as a project root #33
Conversation
- Aalways treat all scm repository meta directories as irrelevant.
I disagree with that decision. |
Hmm, ok. I agree that its a bit of a personal taste as a result of how the projects you work on are configured. 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? |
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. |
So, since the user can override this, I don't think it's worth changing the default. |
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. |
I, on the other hand, hate doing 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. |
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. |
Closing my reqest, not that important as it is mostly a matter of taste anyway. |
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.
This simplifies the generic type definitions.