Re: libgit2 - a true git library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 31 Oct 2008, Shawn O. Pearce wrote:

Junio C Hamano <gitster@xxxxxxxxx> wrote:


I.e. use the supplied custom function to do proprietary magic, such as
reading the object lazily from elsewhere over the network.  And we will
never get that magic bit back.

As a maintainer I'd never accept such a patch.  I'd ask for the
code under read_object_custom, or toss the patch on the floor.
But that doesn't stop them from distributing the patched sources
like above, keeping the fun bits in the closed source portion of
the executable they distribute.

Maybe I just think too highly of the other guy, but I'd hope that
anyone patching libgit2 like above would try to avoid it, because
they'd face merge issues in the future.

the issue that I see is that libgit2 will be (on most systems) a shared library.

what's to stop someone from taking the libgit2 code, adding the magic proprietary piece, and selling a new libgit2 library binary 'just replace your existing shared library with this new one and all your git related programs gain this feature'

they would only face merge issues if they need to keep up to date with you, and git makes it pretty easy to maintain a fork if you only have to do one-way merging (rere)

David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux