Switching to libgit2

[lb1a]

I'm not that involved into klaus so far, but i saw that you sometimes struggle with the limitiations of dulwich. So i want to open up the discussion of switching from dulwich to the libgit2. It has been mentioned in #67 and #94 . So please share your thoughts. @jonashaag already thought loud about it, see the linked issues.

[jonashaag]

libgit2 should at least

• [ ] be comparably fast in its git log equivalent (compared to the git log command line tool. Can be benchmarked with time git log > /dev/null for example with the Django or Linux repositories.)
• [ ] support git blame in a sane way
• [x] support git archive, see https://github.com/libgit2/pygit2/issues/358
• [ ] submodule support would be awesome #1
• [ ] should support rename recognition in commits
• [ ] maybe even fast search? #68
• [ ] maybe nice diffs #78

[Mechazawa]

I'm currently waiting for my pull requests to be pulled before I start working on implementing libgit2 because I can't be bothered with dealing with (if any) merge conflicts or converting that code at a later time.

[tony]

libgit2 itself poses problems being LGPL. It boils down into how layman interpret it, but the end reality is it's never been tested in court, especially in the case of an interpreted, high level, duck-typed, oop language where the "code sharing" habits differ.

LGPL was intended for low-level languages. However, due to the nature of interpreted OOP languages, most pythonistas accustomed to subclassing, copying and pasting this and that, vendorizing modules, et cetera could trigger a derivative themselves out of sheer ignorance. And ignorance is hard to classify - these licenses are legal documents - if we're not lawyers, we can't interpret them.

We trust these licenses implicitly by their ubiquitous usage from a prior generation in open source. The habit to include viral license was brought over to modern libraries, to no real gain. The only real way to fix it is to contact the contributors to relicense it or write a new, clean library from the start.

If a project intends to be permissive, LGPL locks a lot developers / projects out, in various ways downstream and with the passage of time.

I brought the conversation up here. https://github.com/libgit2/libgit2/issues/3050.