Add support for git repositories

[steffenmazur]

It will be very nice if this RepoCop can be used for git repositories.

For example I want to check if a Jira-Track was entered in the commit message. A Jira-Track is defined by a project matchcode like "JRA" or "PM" and is followed by the number.

For example "JRA-101: Name of the bug"

RepoCop could check if "JRA-" was included in the commit message. This is already been done by "LogMessageCondition" I think, where I can define something like that.

But not for git.

Thanks a lot.

[steffen-wilke]

I'm currently thinking about how RepoCop would work with a git repository. It's not really comparable to the SVN scenario. There are two types of git hooks: The ones that are performed client-side (e.g. pre-commit, pre-push, ...) and the ones that are performed on the server-side (e.g. pre-receive, post-receive). My main question currently is: where would RepoCop come into play?

Client-side RepoCop
A client-side Repocop instance would either mean that the developer has to have RepoCop installed locally or there would have be a remote call to some form of RepoCop API. Client-side hooks are not part of the git repository and therefore the distribution would also be tricky.

Server-side RepoCop
Especially the pre-receive hooks alone might be uncomfortable for a developer, because one would have to change (--amend) commits after the fact in order for them to be accepted by the server. On the bright side, post-receive hooks are, to my understanding, fairly similar to the current HookType.PostCommit.

Mainly, the hooks that should prevent commits in the first place (e.g. by checking for related Jira issues) would have to be distributed in my opinion.
So a good solution might include both, client and server-side RepoCop, e.g. a combination of pre-commit, pre-receive and post-receive.

I would honestly favor a solution with one RepoCop instance (on the server) and without the need to distribute the tool and configuration to every developer. And I think some kind of RepoCop validation API would be great to realize this.

[BrightLight]

Right now the one available console application is called Silverseed.RepoCop.Subversion.exe. As the name suggests, this solely targets Subversion. A while ago we moved away from the SharpSvn dependency and instead we call SvnLook and parse the console output.

Therefore, from a purely technical standpoint, you'd have to add a new project Silverseed.RepoCop.Git.exe which calls some git client and parses its output. This should be pretty straight-forward (a pull request would be highly appreciated ;))

But then there's the conceptual side (see remarks by @steffen-wilke). When do you run RepoCop and where? In my opinion it should definitely run on the (central) repository server (if you have one), so that you can be sure that commits follow your rules. However, i a distributed SCM like Git there doesn't need to be such a central repository server. And I guess it's a matter of a personal or company philosophy whether rules have to be applied also for local commits. Do you want to (and can you) force everyone that forks your repository to also have RepoCop setup? Maybe this might work if RepoCop is part of the checkout itself.
In any case, I think it would make sense to move RepoCop to .Net Core, so that it can run on non-Windows OS as well.