Open lb1a opened 10 years ago
libgit2 should at least
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.)git blame
in a sane waygit archive
, see https://github.com/libgit2/pygit2/issues/358I'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.
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.
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 fromdulwich
to thelibgit2
. It has been mentioned in #67 and #94 . So please share your thoughts. @jonashaag already thought loud about it, see the linked issues.