The last post by Ozi is true. The problem is that all of the paths in the project and within the header and source files depend on the repo structure. What is worse is that many of the project examples and applications all have the same project name so you can’t import more than one at a time in the same workset. Changing the project name once the import is done is a bad idea since the project name is also used for the directory structure and doing so will break the paths. Even worse is that importing without copying the files means that the build takes place in the repo so any changes you make change the contents of the repo. Next time you update the repo with a new version all of your old code is in the old repo so little is gained unles you use a tool like unison or meld that can merge changes ... carefully. Again worse if you use the repo in situe then you have to archive the whole thing unless you want to go through the painful task of deleting code you think you did not use. The repo examples and apps are really a look but don’t touch affair. I have had some success cutting and pasting repo example code into a CubeMX created project. But even that is daughnting as it is easy to miss duplication of defines and often hard to track down due to very ambiguous error reporting. I have yet to find an easy way to import repo code after creating a CubeMX project which is imported first. I have built all the examples and apps for F746-Discovery in the repo and I think all but one worked without a hitch.