* 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
* Re: getting list of objects for packing
From: Jakub Narebski @ 2008-10-31 22:23 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, Nicolas Pitre, Git Mailing List
In-Reply-To: <fAUegZ3bxPo8HquZjUM9syW-giYefuAzBtb1XXHQ-TwbmvJvMZvmDA@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Junio C Hamano wrote:
> > 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.
Wasn't there some gitattribute which prohibited deltification of some
files (`delta` or something)? Or wasn't this patch accepted, as I
cannot find such attribute in documentation (gitattributes(5))...
... err, it was added in commit a74db82e15cd8a2c53a4a83e9a36dc7bf7a4c750
(Teach "delta" attribute to pack-objects.) by Junio C Hamano in May
19, _without_ documentation.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Documentation/gitattributes: Add subsection header for each attribute
From: Jakub Narebski @ 2008-10-31 22:24 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
This makes attributes easier to find; before this patch some
attributes had individual subsections, and some didn't.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/gitattributes.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 24e880c..eb64841 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -213,6 +213,9 @@ with `crlf`, and then `ident` and fed to `filter`.
Generating diff text
~~~~~~~~~~~~~~~~~~~~
+`diff`
+^^^^^^
+
The attribute `diff` affects if 'git-diff' generates textual
patch for the path or just says `Binary files differ`. It also
can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
@@ -331,6 +334,9 @@ patterns are available:
Performing a three-way merge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+`merge`
+^^^^^^^
+
The attribute `merge` affects how three versions of a file is
merged when a file-level merge is necessary during `git merge`,
and other programs such as `git revert` and `git cherry-pick`.
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Johannes Schindelin @ 2008-10-31 22:36 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, pasky, srabbelier
In-Reply-To: <1225445204-28000-1-git-send-email-madcoder@debian.org>
Hi,
On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> git_commit_non_empty_tree is added to the functions that can be run from
> commit filters. Its effect is to commit only commits actually touching
> the tree and that are not merge points either.
>
> The option --prune-empty is added. It defaults the commit-filter to
> 'git_commit_non_empty_tree "$@"', and can be used with any other
> combination of filters, except --commit-hook that must used
> 'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"'
> usually to achieve the same result.
I think that the example Sverre posted is better. It might be a bit more
to write out, but at least people can adapt it to their needs (as opposed
to only skip "empty" commits).
However, I would _love_ to see your tests being merged with Sverre's patch
(of course, the tests should use the described procedure, then).
Ciao,
Dscho
^ permalink raw reply
* Re: git archive problem with 1.6.0.3 (maybe regression?)
From: Charles Bailey @ 2008-10-31 22:37 UTC (permalink / raw)
To: Alessandro Guido; +Cc: git
In-Reply-To: <200810312213.32224.ag@alessandroguido.name>
Alessandro Guido wrote:
> [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.
http://git.kernel.org/?p=git/git.git;a=commit;h=ddff8563510a2c5c675d488a02e2642306430fc1
^ permalink raw reply
* Re: [PATCH] Introduce receive.denyDeletes
From: Johannes Schindelin @ 2008-10-31 22:45 UTC (permalink / raw)
To: Jan Krüger; +Cc: Shawn O. Pearce, git, gitster
In-Reply-To: <20081030194503.2f9ece1a@perceptron>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 170 bytes --]
Hi,
On Thu, 30 Oct 2008, Jan Krüger wrote:
> By the way, I love what your mail client did to my name.
I think Shawn forgot to turn his pirate filter off.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2008-10-31 22:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, pasky, srabbelier
In-Reply-To: <alpine.DEB.1.00.0810312334480.22125@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
On Fri, Oct 31, 2008 at 10:36:58PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 31 Oct 2008, Pierre Habouzit wrote:
>
> > git_commit_non_empty_tree is added to the functions that can be run from
> > commit filters. Its effect is to commit only commits actually touching
> > the tree and that are not merge points either.
> >
> > The option --prune-empty is added. It defaults the commit-filter to
> > 'git_commit_non_empty_tree "$@"', and can be used with any other
> > combination of filters, except --commit-hook that must used
> > 'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"'
> > usually to achieve the same result.
>
> I think that the example Sverre posted is better. It might be a bit more
> to write out, but at least people can adapt it to their needs (as opposed
> to only skip "empty" commits).
>
> However, I would _love_ to see your tests being merged with Sverre's patch
> (of course, the tests should use the described procedure, then).
Well Sverre's example is probably the most efficient way to do the task,
though the thing is right now, what one wants is rarely to "just" skip
empty commits, but to do some modifications that does not leave empty
commits.
IOW not doing a modification _then_ a new one, but both at the same
time. Given how slow filter-branch can be, it's better to do one
transformation instead of two.
Note that I don't think we should apply only my patch and not Sverre's,
his proposal just made me think that this was an itch I wanted to
scratch for a long time, and both probably are complementary.
--
·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: git archive problem with 1.6.0.3 (maybe regression?)
From: Alessandro Guido @ 2008-10-31 22:43 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <490B8896.6040007@hashpling.org>
On Friday 31 October 2008 23:37:10 Charles Bailey wrote:
> http://git.kernel.org/?p=git/git.git;a=commit;h=ddff8563510a2c5c675d488a02e
>2642306430fc1
Good. Thank you for the link
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Johannes Schindelin @ 2008-10-31 22:53 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git List
In-Reply-To: <200810312035.20016.fg@one2team.com>
Hi,
On Fri, 31 Oct 2008, Francis Galiegue wrote:
> Unless I'm mistaken (and I probably am), the $(...) construct is
> bash-specific, isn't it?
You're mistaken,
Dscho
P.S.:
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_03
^ permalink raw reply
* Re: libgit2 - a true git library
From: Junio C Hamano @ 2008-10-31 22:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081031220133.GA14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> 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?
Essentially, anything that ends with "_t" ;-)
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_02.html#tag_02_02_02
Look for "Any Header" in the table.
>> 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] prepare deprecation of git-revert
From: Johannes Schindelin @ 2008-10-31 23:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: Pierre Habouzit, git
In-Reply-To: <20081031165003.GA5355@steel.home>
Hi,
On Fri, 31 Oct 2008, Alex Riesen wrote:
> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> >
> > int cmd_revert(int argc, const char **argv, const char *prefix)
> > {
> > +#if 0
> > + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
>
> "git revert" is much shorter to type than "git cherry-pick -R". How
> about renaming "cherry-pick" into something short, like "pick"?
I thought we agreed that we should _never_ remove support for "git
revert"? I mean, we can deprecate it, but I find it pretty strong, and
unnecessary, to break existing users' expectations.
Ciao,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Johannes Schindelin @ 2008-10-31 23:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <490B7FD3.8060003@op5.se>
Hi,
On Fri, 31 Oct 2008, Andreas Ericsson wrote:
> Apart from that, please consider reading Ulrich Drepper's musings on
> library design at http://people.redhat.com/drepper/goodpractice.pdf
I do not know if I want to trust a person that has shown a certain
eagerness to ignore good library design by breaking the well-established
dont-change-apis-on-minor-versions idiom, and instead of listening to
users that have problems as a consequence rather ignore them.
Instead, let's build on the knowledge of people we have learnt to trust,
on this list.
Thank you,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Junio C Hamano @ 2008-10-31 23:14 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>
Nicolas Pitre <nico@cam.org> writes:
> 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.
This reminds me that Shawn earlier in an unrelated thread asked me if I
can relicense builtin-blame.c for JGIT; your reasoning fully matches that
of mine regarding that part of the code.
> 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.
Although I'd be Ok with either GPL + gcc exception on whatever core-ish
(i.e. what will be necessary for libgit2; "blame" would not count) pieces
I have in C-git codebase, "can be linked with anything" allows a gaping
hole to the library, which I'm a bit hesitant to swallow without thinking.
E.g. our read_object() may look like this:
void *read_object(const object_name_t sha1,
enum object_type *type,
size_t *size)
{
...
}
but an extension a closed-source person may sell you back may do:
+typedef void *read_object_fn(const object_name_t,
+ enum object_type *,
+ size_t *);
+read_object_fn read_object_custom = NULL;
void *read_object(const object_name_t sha1,
enum object_type *type,
size_t *size)
{
+ if (read_object_custom != NULL)
+ return read_object_custom(sha1, type, size);
...
}
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.
Although no license asks this, my wish is that if somebody built on top of
what I wrote to make the world a better place, I'd like the same access to
that additional code so that I too can enjoy the improved world. Because
almost all of my code in git.git are under GPLv2, in reality I do not have
any access to your software as long as you do not distribute your
additional code that made the world a better place, which is a bit sad.
^ permalink raw reply
* Re: commit type
From: Johannes Schindelin @ 2008-10-31 23:27 UTC (permalink / raw)
To: 7rans; +Cc: git
In-Reply-To: <loom.20081031T191102-81@post.gmane.org>
Hi,
On Fri, 31 Oct 2008, 7rans wrote:
> David Symonds <dsymonds <at> gmail.com> writes:
>
> > On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire <at> gmail.com>
> > wrote:
> >
> > > Currently I achieve this by adding "[type]" to the end of my commit
> > > messages. But of course that's less than optimal.
> >
> > Why is that less than optimal? It seems a lot less intrusive than what
> > you suggest.
>
> Because it becomes formalized. Which means people can write tools other
> people can use to work with them.
So you want to force this onto all Git users?
If yes: that murmur you hear in the background, it might well be the
collective "thanks, but no thanks" of people who do not want that type of
distinction between different commits.
If no: what would be the real difference from that suffix in the oneline?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Junio C Hamano @ 2008-10-31 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, Pierre Habouzit, git
In-Reply-To: <alpine.DEB.1.00.0811010012320.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Oct 2008, Alex Riesen wrote:
>
>> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
>> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
>> >
>> > int cmd_revert(int argc, const char **argv, const char *prefix)
>> > {
>> > +#if 0
>> > + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
>> > +#endif
>>
>> "git revert" is much shorter to type than "git cherry-pick -R". How
>> about renaming "cherry-pick" into something short, like "pick"?
>
> I thought we agreed that we should _never_ remove support for "git
> revert"? I mean, we can deprecate it, but I find it pretty strong, and
> unnecessary, to break existing users' expectations.
Likewise.
The current state of affairs is that there is no remedy if teachers find
"git checkout -- path" or "git revert HEAD~24" is confusing to new people.
By introducing "git unstage path" or "git cherry-pick -r HEAD~24",
teachers can choose to teach what they feel less confusing, and they do
not have to teach "git checkout -- path" or "git revert HEAD~24". We
should stop there.
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Alex Riesen @ 2008-10-31 23:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081031165814.GD627@artemis.corp>
Pierre Habouzit, Fri, Oct 31, 2008 17:58:14 +0100:
> On Fri, Oct 31, 2008 at 04:50:03PM +0000, Alex Riesen wrote:
> > Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> > >
> > > int cmd_revert(int argc, const char **argv, const char *prefix)
> > > {
> > > +#if 0
> > > + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > > +#endif
> >
> > "git revert" is much shorter to type than "git cherry-pick -R".
> > How about renaming "cherry-pick" into something short, like "pick"?
>
> Do you really use git revert _that_ often ? I don't. And cherry-pick is
> a really usual name for the tool.
Have it 5 times in my bash history of 20k lines. 4 recent, one relatively old.
> FWIW the basic idea is to deprecate revert in a (not so ?) long time,
> and leave git revert unimplemented for ever so that people that would
> like it to be 'git checkout HEAD --' alias it to that, and the ones that
> want to keep the current behaviour alias it to 'git cherry-pick -R'
Well, I kind of got used to it. And it makes sense (as does -R by
cherry-pick, I have to admit). I have no other argument against the
change.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pieter de Bie @ 2008-10-31 23:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Nicolas Pitre, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081031213114.GA21799@artemis.corp>
On 31 okt 2008, at 22:31, 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.
>
> Many of the people needing a library for libgit are probably reading
> the
> list, I'll let them comment
As an implementor of a git GUI, I don't really care what license
libgit2 will be. GitX is currently GPLv2, though that might change
to LGPL to allow it to ship/link with non-GPL libraries. GPL and LGPL
would both suit me.
As a more concrete comment, is there anything you would like to hear
from GUI developers during the development of libgit2? I'm not sure I
can contribute much in terms of code, but if you need any constructive
comments, I can help with that.
- Pieter
^ permalink raw reply
* [PATCH] update-ref --no-deref -d: handle the case when the pointed ref is packed
From: Miklos Vajna @ 2008-10-31 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In this case we did nothing in the past, but we should delete the
reference in fact.
The problem was that when the symref is not packed but the referenced
ref is packed, then we assumed that the symref is packed as well, but
symrefs are never packed.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
This applies on top of 'mv/maint-branch-m-symref' (fa58186).
refs.c | 2 +-
t/t1400-update-ref.sh | 11 +++++++++++
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 8a38e08..0d239e1 100644
--- a/refs.c
+++ b/refs.c
@@ -920,7 +920,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
lock = lock_ref_sha1_basic(refname, sha1, 0, &flag);
if (!lock)
return 1;
- if (!(flag & REF_ISPACKED)) {
+ if (!(flag & REF_ISPACKED) || flag & REF_ISSYMREF) {
/* loose */
const char *path;
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 8139cd6..bd58926 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -82,6 +82,17 @@ test_expect_success "delete symref without dereference" '
'
cp -f .git/HEAD.orig .git/HEAD
+test_expect_success "delete symref without dereference when the referred ref is packed" '
+ echo foo >foo.c &&
+ git add foo.c &&
+ git commit -m foo &&
+ git pack-refs --all &&
+ git update-ref --no-deref -d HEAD &&
+ ! test -f .git/HEAD
+'
+cp -f .git/HEAD.orig .git/HEAD
+git update-ref -d $m
+
test_expect_success '(not) create HEAD with old sha1' "
test_must_fail git update-ref HEAD $A $B
"
--
1.6.0.2
^ permalink raw reply related
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 23:25 UTC (permalink / raw)
To: Bruno Santos; +Cc: git
In-Reply-To: <490B9262.5070905@gmail.com>
Bruno Santos <nayart3@gmail.com> wrote:
> Shawn O. Pearce wrote:
> > During the GitTogether we were kicking around the idea of a ground-up
> > implementation of a Git library.
>
> We should take the opportunity a make it more portable. Instead of using
> the posix api directly we should warp it in "git_" APIs. And be carefull
> with certain APIs like fork or fork+exec [...]
>
> Here's an example, for the 'read' API, on how we can simply do this
> without worries for the posix crowd:
>
> ssize_t git_read(git_fildes_t fildes, void* buf, size_t bufsize);
>
> Were git_fildes_t would be an int for posix and an HANDLE for win32.
...
Yes, already on my mind. _IF_ this carries further I'll be involved
with its development, and I'll make certain its reasonably portable
like you are asking.
There are only a handful of things we really need to from the OS
and I think we can wrap most of them up into little inline stubs
on POSIX (so POSIX folks have no impact) and on Win32 we can have
small stubs (or again inline) so its pretty native on Win32.
Yes, I have considered say NPR or APR; I'm not going there.
Both are nice packages but there's also downsides to bringing them
into libgit2. IMHO its just easier to wrap the handful of things
we really need.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 23:28 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Pierre Habouzit, Nicolas Pitre, git, Scott Chacon
In-Reply-To: <CBF2AF68-BA41-4394-A837-F62864CF8BFB@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> wrote:
> On 31 okt 2008, at 22:31, Pierre Habouzit wrote:
>>
>> Many of the people needing a library for libgit are probably reading
>> the
>> list, I'll let them comment
>
> As a more concrete comment, is there anything you would like to hear
> from GUI developers during the development of libgit2? I'm not sure I
> can contribute much in terms of code, but if you need any constructive
> comments, I can help with that.
We'd like to hear feedback on the API. Look at the operations
your application does with git-core.
Can you express that with the libgit2 API?
If not, why not?
Is it just that the docs are unclear?
Is the API missing?
What would you like to invoke to get the data you need?
...
You are the end-user of the library, so it needs to suit you. Ok,
you aren't the only end-user, but you and other developers like
you... :-)
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <7viqr873x7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]
On Fri, Oct 31, 2008 at 11:14:44PM +0000, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > 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.
>
> Although I'd be Ok with either GPL + gcc exception on whatever core-ish
> (i.e. what will be necessary for libgit2; "blame" would not count) pieces
> I have in C-git codebase, "can be linked with anything" allows a gaping
> hole to the library, which I'm a bit hesitant to swallow without thinking.
Well I wasn't thinking about anything else than what is needed for the
libgit2. I love BSDish for libraries, though like GPL for the actual
_tools_ I write with it.
> E.g. our read_object() may look like this:
>
> void *read_object(const object_name_t sha1,
> enum object_type *type,
> size_t *size)
> {
> ...
> }
>
>
> but an extension a closed-source person may sell you back may do:
>
> +typedef void *read_object_fn(const object_name_t,
> + enum object_type *,
> + size_t *);
> +read_object_fn read_object_custom = NULL;
> void *read_object(const object_name_t sha1,
> enum object_type *type,
> size_t *size)
> {
> + if (read_object_custom != NULL)
> + return read_object_custom(sha1, type, size);
> ...
> }
>
> 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.
Well, for one "we're" not supposed to accept any patch that does that,
and I don't expect that the people who end up maintaining libgit2 will
become rogue. Though if such bits of APIs do exist one day, then well, I
see no license except the GPL that can prevent you from that.
My idea of trying to be able to reuse git.git code is not a necessity,
a new implementation from scratch is likely to be possible. Though we
all know that if the core git contributors don't contribute and
eventually use libgit2 this will not fly. That's why we must think about
it.
I assume given your answer that if libgit2 is BSD you may not be as
motivated to contribute code to it as you are to git.git, and this IMHO
would be a big no-go, like shawn said in another mail.
--
·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] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-10-31 23:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <alpine.DEB.1.00.0810312314190.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin, Fri, Oct 31, 2008 23:14:59 +0100:
> 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.
Corporate policy and very-very incompetent IT service. Besides being
illegal to install actually usable software, there are some of
internal programs which are quite sensitive to perl (any other perl)
appearing anywhere on disk, not to mention PATH (the build system, for
one). Same for cygwin revisions.
I tried using other perl and more modern cygwin, and it can be made to
work, but it is cumbersome and boring. And one more thing to reinstall
after IT wipes your computer because you've got a new disk or they
decided you need winxp instead of w2k, or something else... So I'm
just trying reduce effort I put into what I'm not supposed to do at
work anyway.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 23:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <7viqr873x7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> Although I'd be Ok with either GPL + gcc exception on whatever core-ish
> (i.e. what will be necessary for libgit2; "blame" would not count) pieces
> I have in C-git codebase,
Someday I'm going to come back to you and ask for "blame" in libgit2.
Its an important function to be able to execute for an end-user.
Look at "git gui blame", its a major feature of the GUI.
If your blame implementation will never be available except under
the GPL then either it should be clean-room rewritten under the
library's license, or maybe there is a "libgitblame" that is GPL
and can be optionally linked with libgit2 and a GPL'd application
to get blame support.
>"can be linked with anything" allows a gaping
> hole to the library, which I'm a bit hesitant to swallow without thinking.
>
> E.g. our read_object() may look like this:
>
> void *read_object(const object_name_t sha1,
> enum object_type *type,
> size_t *size)
> {
> ...
> }
>
>
> but an extension a closed-source person may sell you back may do:
>
> +typedef void *read_object_fn(const object_name_t,
> + enum object_type *,
> + size_t *);
> +read_object_fn read_object_custom = NULL;
> void *read_object(const object_name_t sha1,
> enum object_type *type,
> size_t *size)
> {
> + if (read_object_custom != NULL)
> + return read_object_custom(sha1, type, size);
> ...
> }
>
> 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.
> Although no license asks this, my wish is that if somebody built on top of
> what I wrote to make the world a better place, I'd like the same access to
> that additional code so that I too can enjoy the improved world. Because
> almost all of my code in git.git are under GPLv2, in reality I do not have
> any access to your software as long as you do not distribute your
> additional code that made the world a better place, which is a bit sad.
IMHO, its a flaw of the GPL. GitHub anyone? Heck, even Google uses
a lot of GPL'd software internally (yes, we have Linux desktops and
servers) but not all of the software we distribute internally goes
external, so not all of our patches are published. *sigh*
I've actually stayed awake at night sometimes wondering what the
world would be like if the GPL virual clause forced the source code
for a website to be opened, or forced you to publish your code
even if you never distribute binaries beyond "you" (where "you"
is some mega corp in many countries with many employees).
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Junio C Hamano @ 2008-10-31 23:49 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Pieter de Bie, Pierre Habouzit, Nicolas Pitre, git, Scott Chacon
In-Reply-To: <20081031232829.GC14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> You are the end-user of the library, so it needs to suit you. Ok,
> you aren't the only end-user, but you and other developers like
> you... :-)
I will be the end-user of the library because if we want libgit2 to be
anywhere close to successful, you should be able to port C-git to it.
I understand that the apidocs/ is a very early work-in-progress, but
still, it bothers me that it is unclear to me what lifetime rules are in
effect on the in-core objects. For example, in C-git, commit objects are
not just parsed but are modified in place as history is traversed
(e.g. their flags smudged and their parents simplified). You have "flags"
field in commit, which implies to me that the design shares this same
"modified by processing in-place" assumption. It is great for processing
efficiency as long as you are a "run once and let exit(3) clean-up" type
of program, but is quite problematic otherwise. commit.flags that C-git
uses for traversal marker purposes, together with "who are parents and
children of this commit", should probably be kept inside traversal module,
if you want to make this truly reusable.
By the way, I hate git_result_t. That should be "int", the most natural
integral type on the platform.
^ permalink raw reply
* Re: [PATCH] Documented --no-checkout option in git-svn
From: public_vi @ 2008-10-31 22:36 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Deskin Miller
In-Reply-To: <1225390505.19891.41.camel@maia.lan>
OK, agree with all changes. This is my the first patch.
/* not including the patch text as it gets broken by Iceweasel. */
Sam Vilain wrote:
> I think the wording is close enough; here's a version which looks good
> to me and fixes the asciidoc differences.
>
^ 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