Support for .git links

[FlorianReimold]

Context:

This enhancement idea is written in the context of Eclipse eCAL, a C++ project. C++ does not specify a package manager for libraries or let alone a build system. We are using CMake for cross-plattform build descriptions and include libraries as git submodules. Git submodules link to a specific commit on a git repository.

Not all git repositores are hosted on GitHub.

Idea:

For us it would be beneficial to directly provide that exact link to a commit in any git repository to the Dash License Tool. While one can write scripts that convert a link to a GitHub commit to the ClearlyDefined ID format, that is not really possible with e.g. Sourceforge links. Sourceforge also doesn't provide .zip files for every commit - you have to manually request that.

[waynebeaton]

I'm finding all kinds of reasons to support something other than ClearlyDefined-formatted IDs. Converting an obvious direct URL to a resource to ClearlyDefined and then back again is just silly (especially if we're not going to find the resource in the ClearlyDefined data).

Supporting a direct link to a specific commit in a specific repository seems like an obvious choice. This may require some refactoring...

I think that we're also going to have to support cloning a Git repository. That's relatively easy, but will also require some refactoring...

These are good ideas.

[waynebeaton]

I spent some time poking around tonight...

git submodule status --recursive gives us the local path of each submodule along with the SHA. But it doesn't give us a URL. For that, we need look in the .gitmodules file. The combination of the URL and the SHA should give us what we need.

We're investigating another solution that might give us an easy win in cases like this. We have a test instance of OSS Review Toolkit (ORT) that is cloning project repositories and running automatic scans on them. It doesn't appear to have picked up eCAL yet (I'll get the team to investigate why not). If it works like I think/hope it does, just cloning the repository and running a scan on the clone should give us all the information that we need about licensing in the project.

[FlorianReimold]

Those are interesting news! Direct support for git submodules would obviously be a cool thing. If you would parse the .gitmodules file you would get both the path and the URL.

Here you can find the .gitmodules from the eCAL Repository: https://github.com/eclipse-ecal/ecal/blob/master/.gitmodules

This will not be recursive though, i.e. it will not enter the submodules and look for further submodules. In eCAL we are not using recursive submodules anyways, so it would be fine for us. If you want to parse recursive submodules, you can use the command you posted and then enter each directory and call git config --get remote.origin.url (or use git submodule --quiet foreach 'git config --get remote.origin.url' if you prefer git doing that for you)

For getting the commit or tag you can cd with a script into the submodule directory and call
git describe --exact-match --tags (-> for getting the tag, may be emptystring if no exact tag is found)
git rev-parse --verify HEAD (-> for getting the commit hash instead)