I hear you.

Is there any solid reason why this is as such? I'd really recommend a binary purge.

Actually, when we started to work on the HistoryRewriter with @ben, one of the end goal was to dogfood LibGit2Sharp in order to rewrite the history and reduce the size of the repository. At this time, the idea was to extract the binaries and host them externally. Each rewritten commit would contain a powershell script which would download the correct libgit2 binaries.

Is there any solid reason why this is as such?

Yes, there is. Embedding the compiled binaries was a way to reduce the friction for contributors (at least on Windows).

The repo size already reached 100mb.

I'd be ok to shrink it down provided we find a way for contributors to not waste too much time updating to the correct version of libgit2 each time the submodule pointer has been bumped.

Externally hosting the binaries may turn into a burden in the long time run. So, the only option I can think of right now would be to provide a script that would force the init of the libgit2 submodule, and build the binaries on demand (a trimmed and tweaked version of UpdateLibgit2ToSha.ps1). The drawback is that every contributor should have CMake installed on his/her computer to even run the tests.

Another issue is the TeamCity CI server. In order to build libgit2, CMake would have to be installed on the agents (A counter-proposal could be to download the .zip version of CMake, extract it and use it to build libgit2).

Thoughts?

/cc @dahlbyk @kitbellew @ethomson @jamill @spraints @shiftkey @KindDragon

Binaries in the repo #739

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions