* Re: libgit2 - a true git library
From: Nicolas Pitre @ 2008-10-31 20:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081031174745.GA4058@artemis.corp>
On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> Last but not least, I believe parts of git-core are currently easy to
> just take. For example, any code *I* wrote, I hereby give permission to
> relicense it in any of the following licenses: BSD-like, MIT-like,
> WTFPL.
First........... is there really a need to re-license it?
If so then the choice of license is IMHO rather important.
> Nicolas already said I think that he was okay with relicensing his
> work too e.g.
Depends. Sure, I gave permission to copy some of my code for JGIT
because 1) JGIT is Java code in which I have little interest, 2) the
different license was justified by the nature of the JGIT project, and
3) although no license convey this I asked for the C version of git to
remain the authoritative reference and that any improvements done to JGIT
first be usable in the C version under the GPL.
Of course a library might need a different license than the GPL to be
widely useful from a linkage stand point, but the code within that
library does not need to be miles away from the GPL. What I personally
care about is for improvements to my code to always be contributed back,
which pretty much discards BSD-like licenses.
My favorite license for a library is the GPL with the gcc exception,
i.e. what libraries coming with gcc are using. They're GPL but with an
exception allowing them to be linked with anything. And because
everything on a Linux system, including proprietary applications, is
likely linked against those gcc libs, then there is nothing that would
prevent libgit to be linked against anything as well. But the library
code itself has GPL protection.
For reference, here's the exception text:
In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file. (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)
Nicolas
^ permalink raw reply
* Re: libgit2 - a true git library
From: Brian Gernhardt @ 2008-10-31 20:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081031174745.GA4058@artemis.corp>
On Oct 31, 2008, at 1:47 PM, Pierre Habouzit wrote:
> Last but not least, I believe parts of git-core are currently easy to
> just take. For example, any code *I* wrote, I hereby give permission
> to
> relicense it in any of the following licenses: BSD-like, MIT-like,
> WTFPL.
FWIW, I give the same permissions.
> 11 Brian Gernhardt
~~ Brian Gernhardt
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Ian Hilt @ 2008-10-31 20:11 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git List
In-Reply-To: <200810312050.31167.fg@one2team.net>
On Fri, Oct 31, 2008 at 08:50:31PM +0100, Francis Galiegue wrote:
> Le Friday 31 October 2008 19:39:33 Jeff King, vous avez écrit :
> [...]
> >
> > Agreed, and actually I found such a bashism (test ==) last week (though
> > of course it also broke on FreeBSD).
> >
>
> As for bash-isms, a hunt for $(...) also looks necessary...
>
> $ grep -rl '\$([^)]\+)' $(find -type f)|wc -l
> 272
>
> Unless I'm mistaken (and I probably am), the $(...) construct is
> bash-specific, isn't it?
Nope. Read section 2.6.3 Command Substitution here,
<http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html>
^ permalink raw reply
* Re: libgit2 - a true git library
From: david @ 2008-10-31 20:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810311558540.13034@xanadu.home>
On Fri, 31 Oct 2008, Nicolas Pitre wrote:
> On Fri, 31 Oct 2008, Pierre Habouzit wrote:
>
>> Last but not least, I believe parts of git-core are currently easy to
>> just take. For example, any code *I* wrote, I hereby give permission to
>> relicense it in any of the following licenses: BSD-like, MIT-like,
>> WTFPL.
>
> First........... is there really a need to re-license it?
> If so then the choice of license is IMHO rather important.
at the very least you should go from GPLv2 to LGPLv2 for the library.
while it can be argued that this really shouldn't be nessasary, the water
is muddy enough that it would be a very good thing to do this.
I don't see any need to switch to a BSD/MIT/etc license for a library, the
LGPL lets it get linked with those licenses anyway.
> My favorite license for a library is the GPL with the gcc exception,
> i.e. what libraries coming with gcc are using. They're GPL but with an
> exception allowing them to be linked with anything. And because
> everything on a Linux system, including proprietary applications, is
> likely linked against those gcc libs, then there is nothing that would
> prevent libgit to be linked against anything as well. But the library
> code itself has GPL protection.
>
> For reference, here's the exception text:
>
> In addition to the permissions in the GNU General Public License, the
> Free Software Foundation gives you unlimited permission to link the
> compiled version of this file into combinations with other programs,
> and to distribute those combinations without any restriction coming
> from the use of this file. (The General Public License restrictions
> do apply in other respects; for example, they cover modification of
> the file, and distribution when not linked into a combine
> executable.)
<shrug>, I don't see why this is needed with the LGPL, but I'm not a
lawyer.
David Lang
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Francis Galiegue @ 2008-10-31 20:30 UTC (permalink / raw)
To: Git List
In-Reply-To: <20081031201127.GA21345@maintenance05.msc.mcgregor-surmount.com>
Le Friday 31 October 2008 21:11:27 Ian Hilt, vous avez écrit :
[...]
> >
> > Unless I'm mistaken (and I probably am), the $(...) construct is
> > bash-specific, isn't it?
>
> Nope. Read section 2.6.3 Command Substitution here,
>
> <http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html>
My bad, then. I'm too "old-school", I guess ;)
--
fge
^ permalink raw reply
* Re: getting list of objects for packing
From: Nicolas Pitre @ 2008-10-31 20:40 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <TtAUShKh7lOR5rkf1iyWwpMOWoYpT8Mnw-t3Wemdy3tTCd0XiQHdag@cipher.nrlssc.navy.mil>
On Fri, 31 Oct 2008, Brandon Casey wrote:
>
> I'm trying to write a script that will repack large binary or compressed
> objects into their own non-compressed, non-delta'ed pack file.
>
> To make the decision about whether an object should go into this special
> pack file or not, I want the output from 'git cat-file --batch-check'.
> I get it with something similar to:
>
> git rev-list --objects --all |
> sed -e 's/^\([0-9a-f]\{40\}\).*/\1/' |
> git cat-file --batch-check
>
> First question: Is the rev-list call correct?
yes.
> -If I am understanding things right, then the list of objects produced
> by rev-list will be in the right order for piping to pack-objects.
> -The sed statement is stripping off anything after the sha1. Any way to
> get rev-list to print out just the sha1 so that sed is not necessary?
If you strip the data after the SHA1 when pipping into pack-objects then
you'll have horrible delta compression results. The path names after
each SHA1 is used to sort objects when trying to find best matches for
delta compression. So you should preserve those and feed it back
especially with those packs that you still want delta compression for.
> ISSUE TWO:
>
> I have placed these two packs into my own personal repo, and I have unpacked all
> of the other objects so that they are loose.
>
> I thought I could use a similar sequence of commands to pack those loose objects
> into a normal and special pack. I added the --unpacked option to my rev-list
> command, but it still lists many more objects than exist loosely in the repository.
>
> git rev-list --objects --unpacked --all
>
> The man page says:
>
> --objects
> Print the object IDs of any object referenced by the listed
> commits. --objects foo ^bar thus means "send me all object IDs
> which I need to download if I have the commit object bar, but
> not foo".
>
> --unpacked
> Only useful with --objects; print the object IDs that are not
> in packs.
>
> Is this the correct behavior for rev-list --unpacked?
Well, don't think so. Although I have zero unpacked objects in my git
repository, the listing still gives me a hundred objects or so, and they
all appear to be tag objects. There is probably a bug here.
Nicolas
^ permalink raw reply
* Re: getting list of objects for packing
From: Brandon Casey @ 2008-10-31 20:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810311625450.13034@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 31 Oct 2008, Brandon Casey wrote:
>> -The sed statement is stripping off anything after the sha1. Any way to
>> get rev-list to print out just the sha1 so that sed is not necessary?
>
> If you strip the data after the SHA1 when pipping into pack-objects then
> you'll have horrible delta compression results. The path names after
> each SHA1 is used to sort objects when trying to find best matches for
> delta compression. So you should preserve those and feed it back
> especially with those packs that you still want delta compression for.
Ah, I'll have to rethink my script then. Thanks!
-brandon
^ permalink raw reply
* Re: libgit2 - a true git library
From: Nicolas Pitre @ 2008-10-31 20:56 UTC (permalink / raw)
To: david; +Cc: Pierre Habouzit, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <alpine.DEB.1.10.0810311325490.5851@asgard.lang.hm>
On Fri, 31 Oct 2008, david@lang.hm wrote:
> On Fri, 31 Oct 2008, Nicolas Pitre wrote:
>
> > On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> >
> > > Last but not least, I believe parts of git-core are currently easy to
> > > just take. For example, any code *I* wrote, I hereby give permission to
> > > relicense it in any of the following licenses: BSD-like, MIT-like,
> > > WTFPL.
> >
> > First........... is there really a need to re-license it?
> > If so then the choice of license is IMHO rather important.
>
> at the very least you should go from GPLv2 to LGPLv2 for the library.
Sure.
> while it can be argued that this really shouldn't be nessasary, the water is
> muddy enough that it would be a very good thing to do this.
>
> I don't see any need to switch to a BSD/MIT/etc license for a library, the
> LGPL lets it get linked with those licenses anyway.
Right.
> > My favorite license for a library is the GPL with the gcc exception,
> > i.e. what libraries coming with gcc are using. They're GPL but with an
> > exception allowing them to be linked with anything. And because
> > everything on a Linux system, including proprietary applications, is
> > likely linked against those gcc libs, then there is nothing that would
> > prevent libgit to be linked against anything as well. But the library
> > code itself has GPL protection.
> >
> > For reference, here's the exception text:
> >
> > In addition to the permissions in the GNU General Public License, the
> > Free Software Foundation gives you unlimited permission to link the
> > compiled version of this file into combinations with other programs,
> > and to distribute those combinations without any restriction coming
> > from the use of this file. (The General Public License restrictions
> > do apply in other respects; for example, they cover modification of
> > the file, and distribution when not linked into a combine
> > executable.)
>
> <shrug>, I don't see why this is needed with the LGPL, but I'm not a lawyer.
The LGPL also asks that proprietary applications provides necessary
object files so you can link it against an alternative implementation of
the LGPL library if you so wish. With dynamic libraries this is rather
moot but I think that's the main difference.
Nicolas
^ permalink raw reply
* git archive problem with 1.6.0.3 (maybe regression?)
From: Alessandro Guido @ 2008-10-31 21:13 UTC (permalink / raw)
To: git
[please CC: me on replies]
Hi everybody.
With git 1.6.0.3, I get the following error when trying to "git archive" on a
bare clone of the Linux kernel repo:
~ $ cd Kernel/
~/Kernel $ ls
branches config description FETCH_HEAD HEAD hooks info logs objects
packed-refs refs
~/Kernel $ git archive 721d5df > /dev/null
fatal: Not a valid object name
With git 1.6.0.2, on the same tree, it works fine.
^ permalink raw reply
* Re: getting list of objects for packing
From: Junio C Hamano @ 2008-10-31 21:30 UTC (permalink / raw)
To: Brandon Casey; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <JhY9the71dfsAJuojZF2S4BG-SEkshM7XxIWGPBeY9M@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Nicolas Pitre wrote:
>> On Fri, 31 Oct 2008, Brandon Casey wrote:
>
>>> -The sed statement is stripping off anything after the sha1. Any way to
>>> get rev-list to print out just the sha1 so that sed is not necessary?
>>
>> If you strip the data after the SHA1 when pipping into pack-objects then
>> you'll have horrible delta compression results. The path names after
>> each SHA1 is used to sort objects when trying to find best matches for
>> delta compression. So you should preserve those and feed it back
>> especially with those packs that you still want delta compression for.
>
> Ah, I'll have to rethink my script then. Thanks!
Yeah, but wasn't the purpose of your whole exercise to list objects that
do not delta nor compress well with each other, in which case the delta
compression order (aka name hash) would not matter, no?
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 21:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810311558540.13034@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
On Fri, Oct 31, 2008 at 08:24:14PM +0000, Nicolas Pitre wrote:
> On Fri, 31 Oct 2008, Pierre Habouzit wrote:
>
> > Last but not least, I believe parts of git-core are currently easy to
> > just take. For example, any code *I* wrote, I hereby give permission to
> > relicense it in any of the following licenses: BSD-like, MIT-like,
> > WTFPL.
>
> First........... is there really a need to re-license it?
> If so then the choice of license is IMHO rather important.
Hmm yeah, GPL has the viral link issue, and there is a real use of
embedding the libgit in many projects. There is a use for it: front-ends
to git from editors, for closed-source projects of various sorts, ...
All of those right now must do a reimplementation of what they need. As
soon as they need some kind of performance, exec()ing git-* commands
doesn't fly.
Git is currently mostly "GPLv2 or later". A BSDish license was
mentioned, because it's the most permissive one and that nobody cared
that much, though a LGPL/GPL-with-GCC-exception would probably fly.
Many of the people needing a library for libgit are probably reading the
list, I'll let them comment. The kind of license you propose would
totally suite my needs, and I think, most of the one discussed at
GitTogether'08 (except for the eclipse people disliking GPL'ed stuff,
but anyways there was the issue of C code being non pure java anyways,
so maybe Shawn can comment on that bit, I don't recall the exact
specifics I must reckon).
OT: FWIW I prefer BSDish licenses (even the MIT actually) for libraries
because I believe that computing is overall better if everyone can use
the right tool for the task, and I don't want to prevent people from
using good stuff (I hope I write good stuff ;P) because of the license.
And I don't care about people don't giving back to me, those are not the
kind of people who would have given back if it was GPL'ed anyways.
But I understand this is a completely personal view, and I'm not even
trying to persuade you :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git show <tree>: show mode and hash, and handle -r
From: Johannes Schindelin @ 2008-10-31 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, schacon
In-Reply-To: <7vk5bo8y3m.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 31 Oct 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 30 Oct 2008, Junio C Hamano wrote:
> >
> >> I wonder if it would help breaking down cmd_log_init() a bit like this.
> >
> > Sorry, I am quite busy (this is the first time I am able to check my
> > mail since the GitTogether), so I cannot look at that in detail.
> >
> > However, I strongly expect your suggestion not to help: for showing
> > commits, we _want_ recursive to be the default. And switching that on
> > devoids us from being able to DIFF_OPT_TST(.., RECURSIVE) to detect if
> > the user said '-r' _explicitely_.
>
> You can turn on recursive unconditionally for the normal "show
> committish" case, and check for explicit "-r" for "show treeish" that
> was bolted-on much later, can't you?
No, I can't, because cmd_show() uses setup_revisions() (actually, this
is called by cmd_log_init()) not only to parse the command line arguments,
but also the objects to show.
The only way I could imagine this working is to turn _off_ FORMAT_PATCH,
do the parsing, then check if RECURSIVE was set, then turn _on_
FORMAT_PATCH and call diff_setup_done().
But that feels just as awful.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Ian Hilt @ 2008-10-31 21:33 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225456609-694-3-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 01:36:48PM +0100, Pierre Habouzit wrote:
> +GIT: Please enter your email below this line.
At first glance I thought this meant to enter my email address here.
So, instead of "email" would "message" be better? Although on second
glance I realized this is where the body of the message went. Not sure
if this is worth changing.
Ian
^ permalink raw reply
* Re: [PATCH 3/3] git send-email: add --annotate option
From: Ian Hilt @ 2008-10-31 21:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225450632-7230-4-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 11:57:12AM +0100, Pierre Habouzit wrote:
> This allows to review every patch (and fix various aspects of them, or
> comment them) in an editor just before being sent. Combined to the fact
> that git send-email can now process revision lists, this makes git
> send-email and efficient way to review and send patches interactively.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> Documentation/git-send-email.txt | 11 +++++++++++
> git-send-email.perl | 26 ++++++++++++++++++++++++--
> 2 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index cafff1a..9ee81d5 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -37,6 +37,11 @@ The --bcc option must be repeated for each user you want on the bcc list.
> +
> The --cc option must be repeated for each user you want on the cc list.
>
> +--annotate::
> + Review each patch you're about to send in an editor. The setting
> + 'sendemail.multiedit' defines if this will spawn one editor per patch
> + or one for all of them at once.
> +
> --compose::
> Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
> introductory message for the patch series.
> @@ -204,6 +209,12 @@ sendemail.aliasfiletype::
> Format of the file(s) specified in sendemail.aliasesfile. Must be
> one of 'mutt', 'mailrc', 'pine', or 'gnus'.
>
> +sendemail.multiedit::
> + If true (default), a single editor instance will be spawned to edit
> + files you have to edit (patches when '--annotate' is used, and the
> + summary when '--compose' is used). If false, files will be edited one
> + after the other, spawning a new editor each time.
> +
>
> Author
> ------
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 0d50ee2..65c254d 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -48,6 +48,7 @@ git send-email [options] <file | directory | rev-list >
> --bcc <str> * Email Bcc:
> --subject <str> * Email "Subject:"
> --in-reply-to <str> * Email "In-Reply-To:"
> + --annotate * Review each patch that will be sent in an editor.
> --compose * Open an editor for introduction.
>
> Sending:
> @@ -130,7 +131,8 @@ my $compose_filename = ".msg.$$";
>
> # Variables we fill in automatically, or via prompting:
> my (@to,@cc,@initial_cc,@bcclist,@xh,
> - $initial_reply_to,$initial_subject,@files,$author,$sender,$smtp_authpass,$compose,$time);
> + $initial_reply_to,$initial_subject,@files,
> + $author,$sender,$smtp_authpass,$annotate,$compose,$time);
>
> my $envelope_sender;
>
> @@ -151,6 +153,17 @@ if ($@) {
> # Behavior modification variables
> my ($quiet, $dry_run) = (0, 0);
>
> +# Handle interactive edition of files.
s/edition/editing/;
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Pierre Habouzit @ 2008-10-31 21:38 UTC (permalink / raw)
To: Ian Hilt; +Cc: git
In-Reply-To: <20081031213338.GB21345@maintenance05.msc.mcgregor-surmount.com>
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
On Fri, Oct 31, 2008 at 09:33:38PM +0000, Ian Hilt wrote:
> On Fri, Oct 31, 2008 at 01:36:48PM +0100, Pierre Habouzit wrote:
> > +GIT: Please enter your email below this line.
>
> At first glance I thought this meant to enter my email address here.
> So, instead of "email" would "message" be better? Although on second
> glance I realized this is where the body of the message went. Not sure
> if this is worth changing.
Well, this line sounds kind of awkward actually, so I was even thinking
about removing it.
Decent editors should probably have a plugin to put the cursor here and
be done with it.
In fact what looks odd is the GIT: stuff. a line looking like:
--- write your message below this line ---
Looks 10x better, though need some code to strip it out if the user kept
it, and I'm lazy, GIT: stuff is automatically removed...
But if that's the only thing that you don't like in the series, I'm
glad, this is quite a minor issue ;)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: getting list of objects for packing
From: Brandon Casey @ 2008-10-31 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <7v7i7o8nc5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Nicolas Pitre wrote:
>>> On Fri, 31 Oct 2008, Brandon Casey wrote:
>>>> -The sed statement is stripping off anything after the sha1. Any way to
>>>> get rev-list to print out just the sha1 so that sed is not necessary?
>>> If you strip the data after the SHA1 when pipping into pack-objects then
>>> you'll have horrible delta compression results. The path names after
>>> each SHA1 is used to sort objects when trying to find best matches for
>>> delta compression. So you should preserve those and feed it back
>>> especially with those packs that you still want delta compression for.
>> Ah, I'll have to rethink my script then. Thanks!
>
> Yeah, but wasn't the purpose of your whole exercise to list objects that
> do not delta nor compress well with each other, in which case the delta
> compression order (aka name hash) would not matter, no?
The script I wrote actually starts up two pack-objects instances and I was
writing the objects I wanted to pack _normally_ to one, and the ones that I
did not want compressed/deltafied to the other (which was started with
--no-reuse-object --window=0 --depth=0 --compression=0).
I didn't mentioned that fact in my first email, but I'm very glad Nico
made his point.
-brandon
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 21:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810311651451.13034@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 31 Oct 2008, david@lang.hm wrote:
> > On Fri, 31 Oct 2008, Nicolas Pitre wrote:
> > > On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> > >
> > > > Last but not least, I believe parts of git-core are currently easy to
> > > > just take. For example, any code *I* wrote, I hereby give permission to
> > > > relicense it in any of the following licenses: BSD-like, MIT-like,
> > > > WTFPL.
> > >
> > > First........... is there really a need to re-license it?
> > > If so then the choice of license is IMHO rather important.
Some people want to be able to link the library into an application
that they redistribute binaries of, but not sources to. Those folks
have also volunteered to help write the library. If they put their
code where their mouth is, then I think they should be able to use
their code the way they want to.
That said, I think the license choice that makes the most sense
here is probably LGPL or GPL+gcc exception, like you note below.
BSD and MIT are probably not serious contenders.
> > at the very least you should go from GPLv2 to LGPLv2 for the library.
>
> Sure.
Well, we cannot do a GPL->LGPL switch on code without author
permission for that sort of re-licensing.
That said, I think many authors of git.git code would be more
comfortable with a GPL->LGPL change, where they wouldn't be OK with
a GPL->BSD/MIT change. There may be some folks though who still
wouldn't accept a GPL->LGPL move.
> > > My favorite license for a library is the GPL with the gcc exception,
...
> > >
> > > For reference, here's the exception text:
> > >
> > > In addition to the permissions in the GNU General Public License, the
> > > Free Software Foundation gives you unlimited permission to link the
> > > compiled version of this file into combinations with other programs,
> > > and to distribute those combinations without any restriction coming
> > > from the use of this file. (The General Public License restrictions
> > > do apply in other respects; for example, they cover modification of
> > > the file, and distribution when not linked into a combine
> > > executable.)
> >
> > <shrug>, I don't see why this is needed with the LGPL, but I'm not a lawyer.
>
> The LGPL also asks that proprietary applications provides necessary
> object files so you can link it against an alternative implementation of
> the LGPL library if you so wish. With dynamic libraries this is rather
> moot but I think that's the main difference.
I'm happy with either the LGPL or the GPL+exception above. If I
read these correctly the GPL+exception allows one to distribute
static executables without source or object files, so long as the
library source wasn't modified. I'd almost prefer just using the
standard LGPL then, static linking isn't very common anymore.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 21:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081031214356.GX14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> That said, I think the license choice that makes the most sense
> here is probably LGPL or GPL+gcc exception, like you note below.
> BSD and MIT are probably not serious contenders.
I should clarify that I said the above paragraph...
> That said, I think many authors of git.git code would be more
> comfortable with a GPL->LGPL change, where they wouldn't be OK with
> a GPL->BSD/MIT change. There may be some folks though who still
> wouldn't accept a GPL->LGPL move.
because of this paragraph.
Like Pierre I also prefer a BSD style license, and JGit is under
that, as it offers quite a bit of freedom for the consumer of
the code.
I'm also not too worried about not getting changes back. If someone
forks away from the base project and doesn't contribute back,
that's their problem. So long as the base project has sufficient
momentum under it making changes and improving things, everyone
else will want to pull and either face merge-hell once in a while,
or send changes back upstream to avoid merge-hell.
But I doubt Git regulars share our views on this, and I think most
of the major contributors to git.git have stated multiple times
that they prefer a GPL style license on their code. I want those
people to contribute to libgit2 (assuming the project moves past the
pie-in-the-sky theory stage), so I want the license to be something
they will be comfortable with.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 21:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, david, git, Scott Chacon
In-Reply-To: <20081031214356.GX14786@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
On Fri, Oct 31, 2008 at 09:43:56PM +0000, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 31 Oct 2008, david@lang.hm wrote:
> > > at the very least you should go from GPLv2 to LGPLv2 for the library.
> >
> > Sure.
>
> Well, we cannot do a GPL->LGPL switch on code without author
> permission for that sort of re-licensing.
>
> That said, I think many authors of git.git code would be more
> comfortable with a GPL->LGPL change, where they wouldn't be OK with
> a GPL->BSD/MIT change. There may be some folks though who still
> wouldn't accept a GPL->LGPL move.
FWIW, I dislike the LGPL for many reasons, and I prefer 100x times a GPL
with GCC kind of exceptions. But if other people hate it, I wont be
be a problem and refuse it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <7vfxmc8r8g.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> >> * proper public "stuff" naming (I e.g. realy like types names -- not
> >> struct or enum tags, that I don't really care -- ending with _t as
> >> it helps navigating source.
> >
> > Fixed, types now end in _t.
>
> Ugh.
>
> You could talk me into it if you promise never typedef structures (or
> pointer to structures) with such symbols, I guess.
I should write that one down in CONVENTIONS.
IMHO:
typedef uint32_t uid_t; /* sane */
typedef enum {...} status_t; /* sane */
typedef struct foo_t foo_t; /* sane */
typedef struct {...} foo_t; /* borderline insane */
typedef char* str_t; /* totally nuts */
typedef char**** str_pppp_t; /* totally nuts */
Hiding the fact that scalar types like a uid_t are 32 bits on
this system is reasonable. Heck, uid_t is already in POSIX,
we shouldn't fight that sort of idea. It at least improves
documentation somewhat.
Hiding the fact that some scalar type is an enum, so you don't have
to type "enum blah" everywhere is also reasonable. Its slightly
better than #define some magic constants and passing an int
everywhere. Its a reasonable balance between reducing keystrokes
and keeping the code semi-self-documenting.
Hiding the fact that an opaque struct (or union) you cannot ever
see the members of is a struct or union is good API design. You can
later change the major class from struct to union or back, or totally
redefine it, but the caller never needs to know what is going on.
Hiding a pointer is wrong. Callers should know they are getting a
pointer, or are being asked to supply a pointer-to-a-pointer. So the
"FILE*" stdio functions are sane, because we don't know what is under
a FILE type but we do know when we are dealing with a pointer to one.
My original proposal didn't stick _t onto the end of everything,
because I didn't think it was really necessary. I'm fine with it
either way. It may be better to include the _t suffix, it seems
to be somewhat common in libraries.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-10-31 21:59 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081031174745.GA4058@artemis.corp>
Pierre Habouzit wrote:
> On Fri, Oct 31, 2008 at 05:07:04PM +0000, Shawn O. Pearce wrote:
>> During the GitTogether we were kicking around the idea of a ground-up
>> implementation of a Git library. This may be easier than trying
>> to grind down git.git into a library, as we aren't tied to any
>> of the current global state baggage or the current die() based
>> error handling.
>>
>> I've started an _extremely_ rough draft. The code compiles into a
>> libgit.a but it doesn't even implement what it describes in the API,
>> let alone a working Git implementation. Really what I'm trying to
>> incite here is some discussion on what the API looks like.
>
> I know this isn't actually helping a lot to define the real APIs, but we
> should really not repeat current git mistakes and have a really uniform
> APIs, meaning that first we must decide:
> * proper namespacing (e.g. OBJ_* looks like failure to me, it's a way
> too common prefix);
>
As it's the git-lib, all public functions should almost certainly be
prefixed with "git" or "git_". I favor "git_".
> * proper public "stuff" naming (I e.g. realy like types names -- not
> struct or enum tags, that I don't really care -- ending with _t as
> it helps navigating source.
>
*_t types are reserved by POSIX for future implementations, so that's
a no-go (although I doubt POSIX will ever make types named git_*_t).
Apart from that, please consider reading Ulrich Drepper's musings on
library design at http://people.redhat.com/drepper/goodpractice.pdf
It's pretty short but brings up nearly all the crucial points one really
don't want to forget.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 22:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <490B7FD3.8060003@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>> * proper public "stuff" naming (I e.g. realy like types names -- not
>> struct or enum tags, that I don't really care -- ending with _t as
>> it helps navigating source.
>
> *_t types are reserved by POSIX for future implementations, so that's
> a no-go (although I doubt POSIX will ever make types named git_*_t).
Yikes. Anyone know where a concise list of the reserved names are?
> Apart from that, please consider reading Ulrich Drepper's musings on
> library design at http://people.redhat.com/drepper/goodpractice.pdf
I think I've read that before, but I'll skim over it again.
Thanks for the link.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Ian Hilt @ 2008-10-31 22:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081031213803.GB21799@artemis.corp>
On Fri, Oct 31, 2008 at 10:38:03PM +0100, Pierre Habouzit wrote:
> On Fri, Oct 31, 2008 at 09:33:38PM +0000, Ian Hilt wrote:
> > On Fri, Oct 31, 2008 at 01:36:48PM +0100, Pierre Habouzit wrote:
> > > +GIT: Please enter your email below this line.
> >
> > At first glance I thought this meant to enter my email address here.
> > So, instead of "email" would "message" be better? Although on second
> > glance I realized this is where the body of the message went. Not sure
> > if this is worth changing.
>
> Well, this line sounds kind of awkward actually, so I was even thinking
> about removing it.
>
> Decent editors should probably have a plugin to put the cursor here and
> be done with it.
>
>
> In fact what looks odd is the GIT: stuff. a line looking like:
>
> --- write your message below this line ---
>
> Looks 10x better, though need some code to strip it out if the user kept
> it, and I'm lazy, GIT: stuff is automatically removed...
Or, to follow the convention of git-status and git-commit, you could do
this with "# ".
So something like,
--->8---
From: Ian Hilt <ihilt@mcgregor-surmount.com>
Date: Fri, 31 Oct 2008 17:55:46 -0400
Subject: [PATCH] Use a hash instead of GIT: for line removal
Signed-off-by: Ian Hilt <ihilt@mcgregor-surmount.com>
---
git-send-email.perl | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5cebb40..c6e21a8 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -427,7 +427,7 @@ sub get_patch_subject($) {
while (my $line = <$fh>) {
next unless ($line =~ /^Subject: (.*)$/);
close $fh;
- return "GIT: $1\n";
+ return "# $1\n";
}
close $fh;
die "No subject line in $fn ?";
@@ -446,14 +446,14 @@ if ($compose) {
print C <<EOT;
From $tpl_sender # This line is ignored.
-GIT: Lines beginning in "GIT: " will be removed.
-GIT: Consider including an overall diffstat or table of contents
-GIT: for the patch you are writing.
+# Lines beginning in "# " will be removed.
+# Consider including an overall diffstat or table of contents
+# for the patch you are writing.
From: $tpl_sender
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
-GIT: Please enter your email below this line.
+# --- write your message below this line ---
EOT
for my $f (@files) {
@@ -479,7 +479,7 @@ EOT
my $in_body = 0;
my $summary_empty = 1;
while(<C>) {
- next if m/^GIT: /;
+ next if m/^# /;
if ($in_body) {
} elsif (/^\n$/) {
$in_body = 1;
--->8---
> But if that's the only thing that you don't like in the series, I'm
> glad, this is quite a minor issue ;)
I've thought something like this would be a good thing. An editor makes
things easier to fix than the command-line.
Ian
^ permalink raw reply related
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Johannes Schindelin @ 2008-10-31 22:14 UTC (permalink / raw)
To: Alex Riesen
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <20081031070003.GA4458@blimp.localdomain>
Hi,
On Fri, 31 Oct 2008, Alex Riesen wrote:
> ActiveState Perl on Windows is portable? To another windows, maybe.
/me wonders why you could not use the Perl that ships with Git for
Windows, at least for the purposes of Git.
Ciao,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Nicolas Pitre @ 2008-10-31 22:10 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081031213114.GA21799@artemis.corp>
On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> Git is currently mostly "GPLv2 or later". A BSDish license was
> mentioned, because it's the most permissive one and that nobody cared
> that much, though a LGPL/GPL-with-GCC-exception would probably fly.
I do care. I think the BSD license is too permissive. There are really
nifty pieces of code in Git that I would be really sorry to see go
proprietary.
> Many of the people needing a library for libgit are probably reading the
> list, I'll let them comment. The kind of license you propose would
> totally suite my needs, and I think, most of the one discussed at
> GitTogether'08 (except for the eclipse people disliking GPL'ed stuff,
> but anyways there was the issue of C code being non pure java anyways,
> so maybe Shawn can comment on that bit, I don't recall the exact
> specifics I must reckon).
Eclipse is Java and that issue is already solved with JGIT which doesn't
reuse C code from git.
> OT: FWIW I prefer BSDish licenses (even the MIT actually) for libraries
> because I believe that computing is overall better if everyone can use
> the right tool for the task, and I don't want to prevent people from
> using good stuff (I hope I write good stuff ;P) because of the license.
Everybody can and does link against glibc on Linux which is LGPL. So
that doesn't affect "usage".
> And I don't care about people don't giving back to me, those are not the
> kind of people who would have given back if it was GPL'ed anyways.
> But I understand this is a completely personal view, and I'm not even
> trying to persuade you :)
Sure, and that's where we differ. I let you use my code for free, as
long as you give me back your improvements to it. This way everybody
stays honnest. I think this is Linus' view as well which he often
resume as "tit for tat".
Nicolas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox