* 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: Pierre Habouzit @ 2008-10-31 20:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031195711.GW14786@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]
On Fri, Oct 31, 2008 at 07:57:11PM +0000, Shawn O. Pearce wrote:
> This "fixes" the "we leak everything" behavior and allows
> applications to have multiple pools on different threads if
> it needs to. Thus the core git_revp_t isn't thread-safe and
> doesn't get weighed down by locking if the application wants
> multiple threads.
Note that on Linux (and also BSDs I think) many pthread locking
functions have stubs in the glibc and cost 0 until you use the
libpthread. So unless we need to use locking inside the tight-loop, it's
virtually free to write a thread-safe library (a function call is
basically 10 times cheaper than an xchg-based lock).
(Though for git it would suck as we get libpthread in our depends
through some of the other dependencies.
Another way is to use function pointers for the locking, and have a
function to make the object store thread safe by setting the pointers to
functions actually doing locking, and to let it point to functions doing
nothing else.
It looks unrealistic to me to let people deal with the locking,
especially if we mean this library to _also_ be used in language
bindings, hence used in sloppily written scripts.
But of course, if locking calls are used in the tight loop that would
rather suck :/
> Pierre Habouzit <madcoder@debian.org> wrote:
> >
> > Well, I propose the following: we set-up on GNU-ld + gcc enabled systems
> > all what is needed to use symbol visibility, which isn't that intrusive,
> > and also rather easy given your GIT_EXPORT macro definition.
>
> Yes, agreed. Only I don't know how to do it myself. I know its
> possible, so if someone wants to contribute a patch for this ... :-)
I will, basically, you need to build everything with -fvisibilty=hidden
in your CFLAGS, and mark the prototypes of symbols you want to export
with __attribute__((visibility("default"))) (that you can set into your
EXPORT_GIT macro when you're building with __GNUC__).
You don't even need a linker script (unless we're going to do some
symbol versioning but I'm unsure whether it's that useful for now).
> > No, my worry was rather wrt git core itself, I really think we _must_
> > make it link against libgit2 if we want libgit2 to stay current, but git
> > core will _very likely_ need the private stuff, and it _will_ be a
> > problem. I mean we cannot seriously so-name a library and show its guts
> > at the same time, and I'm unsure how to fix that problem. _that_ was my
> > actual question.
>
> Hmmph. I agree git-core needs to link to libgit2.
>
> I disagree it needs private bits. If we do the library right
> git-core can use the public API. And where it cannot its either
> not something that is "right" for libgit2
> (e.g. its parseopts and
> we aren't committed yet to including option parsing)
Sure, I didn't mean we have to put it in libgit2, it's highly UI related
and other tool may want to use something else, and it makes no sense for
many languages that have their library already (python, perl do e.g.).
> or its highly
> experimental and we shouldn't put it into the library (and thus
> also git-core) until its more frozen.
>
> That said, I don't think its criminal to have git-core include and
> link to a static libgit2, especially if git-core's usage of the
> library is ahead of what the library itself is able to expose at
> the present time.
Okay, we'll see how that turns out to work then :)
> Off the top of my head some really important ones:
>
> diff-delta.c
> object.c
> patch-delta.c
> refs.c
> revision.c
> sha1_file.c
> sha1_name.c
>
> They form a pretty large part of the guts of what most people want
> from a git library.
>
> Slightly less important, but still fairly core:
>
> builtin-fetch-pack.c
> builtin-send-pack.c
> connect.c
> remote.c
> transport.c
>
> Is most of the client side of the git:// transport, something people want.
Okay I'll let people mention what they would like to see too, and I'll
work from that then.
--
·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] Avoid using non-portable `echo -n` in tests.
From: Junio C Hamano @ 2008-10-31 20:10 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git List
In-Reply-To: <200810312050.31167.fg@one2team.net>
Francis Galiegue <fg@one2team.net> writes:
> Unless I'm mistaken (and I probably am), the $(...) construct is
> bash-specific, isn't it?
You are.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Junio C Hamano @ 2008-10-31 20:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081031184154.GV14786@spearce.org>
"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.
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Francis Galiegue @ 2008-10-31 19:35 UTC (permalink / raw)
To: Git List
In-Reply-To: <20081031183933.GA3577@sigill.intra.peff.net>
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?
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 19:57 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Scott Chacon
In-Reply-To: <20081031185435.GC8464@artemis.corp>
Yet more updates to the API:
http://www.spearce.org/projects/scm/libgit2/apidocs/html/modules.html
In particular I've started to define what revision machinary might
look like, based somewhat on JGit's (public) RevWalk API. The guts
of how to make it work of course aren't yet defined.
My goal here is to have the git_revp_t be non-thread safe, but
also to contain the entire object pool, so git_revp_free() will
dispose of any and all git_commit_t's which were created from it.
This "fixes" the "we leak everything" behavior and allows
applications to have multiple pools on different threads if
it needs to. Thus the core git_revp_t isn't thread-safe and
doesn't get weighed down by locking if the application wants
multiple threads.
Pierre Habouzit <madcoder@debian.org> wrote:
>
> Well, I propose the following: we set-up on GNU-ld + gcc enabled systems
> all what is needed to use symbol visibility, which isn't that intrusive,
> and also rather easy given your GIT_EXPORT macro definition.
Yes, agreed. Only I don't know how to do it myself. I know its
possible, so if someone wants to contribute a patch for this ... :-)
> No, my worry was rather wrt git core itself, I really think we _must_
> make it link against libgit2 if we want libgit2 to stay current, but git
> core will _very likely_ need the private stuff, and it _will_ be a
> problem. I mean we cannot seriously so-name a library and show its guts
> at the same time, and I'm unsure how to fix that problem. _that_ was my
> actual question.
Hmmph. I agree git-core needs to link to libgit2.
I disagree it needs private bits. If we do the library right
git-core can use the public API. And where it cannot its either
not something that is "right" for libgit2 (e.g. its parseopts and
we aren't committed yet to including option parsing) or its highly
experimental and we shouldn't put it into the library (and thus
also git-core) until its more frozen.
That said, I don't think its criminal to have git-core include and
link to a static libgit2, especially if git-core's usage of the
library is ahead of what the library itself is able to expose at
the present time.
> I'd say we should do both at the same time. Asking people if they would
> agree to relicense code can be done in parallel. We could extract a list
> of source files that we may need (my extraction included stuff that is
> very unlikely to be useful like test-*.c that aren't useful, and some
> that are already BSD I think), and see who it yields. It should be
> possible to do a matrix source-file x people and see on a per-file basis
> what they think.
>
> If someone gives me the list of files we should consider (I'm not sure
> about a good list right now) I could do the matrix at some fixed sha1
> from git.git using git blame -C -M -M -w, and ask people see where it
> leads us ?
Off the top of my head some really important ones:
diff-delta.c
object.c
patch-delta.c
refs.c
revision.c
sha1_file.c
sha1_name.c
They form a pretty large part of the guts of what most people want
from a git library.
Slightly less important, but still fairly core:
builtin-fetch-pack.c
builtin-send-pack.c
connect.c
remote.c
transport.c
Is most of the client side of the git:// transport, something people want.
--
Shawn.
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Nicolas Pitre @ 2008-10-31 19:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jakub Narebski, Thanassis Tsiodras, git
In-Reply-To: <vpqej1wra1c.fsf@bauges.imag.fr>
On Fri, 31 Oct 2008, Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Thanassis Tsiodras wrote:
> >
> >> So I have to git-gc on my side (after the commits), git-gc on the remote,
> >> and then git-push?
> >
> > Perhaps I haven't made myself clear.
> >
> > On the local side: git-commit creates loose (compressed, but not
> > deltified) objects. git-gc packs and deltifies.
> >
> > On the remote side (for smart protocols, i.e. git and ssh): git
> > creates _thin_ pack, deltified;
>
> I don't understand this point: the OP talks about pushing, so isn't
> the pack created on the _local_ machine (and then sent to the remote)?
Yes, the pack is created on the fly when pushing, regardless if the repo
is already packed or not locally. The only difference a locally packed
repo provides is a shorter "Compressing objects" phase when pushing
that's all. The packedness of the remote has no effect at all.
Nicolas
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Francis Galiegue @ 2008-10-31 19:50 UTC (permalink / raw)
To: Git List
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?
--
fge
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Nicolas Pitre @ 2008-10-31 19:47 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: Pierre Habouzit, git
In-Reply-To: <f1d2d9ca0810310416n1e9f3700if49951a05cae9a37@mail.gmail.com>
On Fri, 31 Oct 2008, Thanassis Tsiodras wrote:
> Actually, after using git-gc, git-repack isn't really needed...
> git-gc identifies that the two files are very similar and re-deltifies
> (see the du -s -k outputs in the original mail, after git-gc we have
> in fact lower usage than the first commit).
git-gc does call git-repack already. In fact, git-gc is only a
convenience wrapper for a couple maintenance commands.
> My question is basically...
> (a) why doesn't git detect this during commit and needs a git-gc
Because we want commit operations to be fast. One of many usage
scenarios for git is to apply a large amount of patches in one go,
meaning many commits per second. The gc operation is potentially long,
can be done unfrequently and deferred any time, like when you don't have
to wait for it.
> (b) whether after git-gc I would have seen the massive difference
> during a subsequent git-push or not
No. A push does create a pack with best size reduction already, whether
or not your local or remote repositories are already packed. The only
advantage for having your local repository packed is in the time
required to create that same pack to be pushed.
As mentioned already, you should consider the --thin switch if you are
pushing over a slow link. If the remote repository already has
necessary objects then all the pushed pack will contain is all deltas.
The reason why --thin is not activated by default is because most people
do pulls from a central server and only few people do pushes to such a
server, and while thin packs do reduce the transmission size they do
create slightly bigger packs on the receiving end which is best avoided
on a busy server.
Nicolas
^ permalink raw reply
* getting list of objects for packing
From: Brandon Casey @ 2008-10-31 19:32 UTC (permalink / raw)
To: Git Mailing List
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?
-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?
Then I want to parse the output from cat-file and use an external program
to detect the file format. Here is a simplified version:
| while read sha1 type size; do
if [ $type = "blob" ]; then
if ! ( git cat-file blob "$sha1" | file -b - | grep text ) &&
[ $size -ge $threshhold ]; then
# pack into special pack
else
# pack normally into normal pack
fi
fi
done
All of this has actually been rewritten into a perl script, so ignore any
syntax mistakes.
I have successfully created two of the pack files that I have been trying to
make. Where the definition of successful means that after removing the existing
packs and objects, and putting in place the two pack files that I generated,
'git fsck --full' prints no errors and exits successfully.
These two packs will be placed into a central repository.
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?
Am I mis-reading the --unpacked text, or should it be changed?
-brandon
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Nicolas Pitre @ 2008-10-31 19:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Thanassis Tsiodras, git
In-Reply-To: <20081031110245.GA22633@artemis.corp>
On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> On Fri, Oct 31, 2008 at 09:43:43AM +0000, Thanassis Tsiodras wrote:
> > So even though the xdelta is just 8KB, and git-gc actually finds out
> > that indeed
> > the new file is very similar to the old one, the initial commit of the
> > new version
> > in the repos is not taking advantage.
>
> Have you tried to git repack with aggressive options, like:
>
> git repack --window=500 --depth=500 \
> --window-memory=<fair amount of your physical RAM>
That wouldn't bring any benefit in this case.
Nicolas
^ permalink raw reply
* Re: commit type
From: 7rans @ 2008-10-31 19:20 UTC (permalink / raw)
To: git
In-Reply-To: <ee77f5c20810311104m6044bf70r1d9d405fa04454e0@mail.gmail.com>
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.
Having the type embedded in commit message not only clutters up the commit
messages, but different people would do it differently, using different brackets
or putting it the start or the end of the message, etc.
And of course it would be easier to ask git to list certain types of commits if
it knew about them.
7rans.
^ permalink raw reply
* Re: large publicly accessible HTTP archive?
From: Daniel Stenberg @ 2008-10-31 19:01 UTC (permalink / raw)
To: git
In-Reply-To: <490B3B35.60508@larsen.st>
On Fri, 31 Oct 2008, Bryan Larsen wrote:
> We "fixed" the problem by turning off CURL_MULTI and ignored the problem.
>
> Our problems were against curl 7.16.2.
Right, libcurl has had 8 releases since with perhaps an average of 30 bugfixes
per release so...
I'm not aware of any current known libcurl bugs with the multi interface and
"simple" HTTP transfers such as this.
--
/ daniel.haxx.se - libcurl hacker
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Theodore Tso @ 2008-10-31 19:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Pierre Habouzit, git
In-Reply-To: <m33aichgc1.fsf@localhost.localdomain>
On Fri, Oct 31, 2008 at 09:36:33AM -0700, Jakub Narebski wrote:
> > +#if 0
> > + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
>
> By the way, Mercurial names this command IIRC 'hg backout'.
By the way, BitKeeper names this command "bk undo" (which is another
reason why I would advocate against "git undo" as a syntatic sugar for
"git checkout HEAD -- $*") --- not that I think there are too many BK
refugees that might want to switch to git, but it shows that "undo"
has its own ambiguities; gk uses "undo" the same way we currently use
"git revert".
For people who argue that "git cherry-pick --revert" or "git
cherry-pick -R" is too long, I'd argue that for most people its not a
common command, and for those for which it is common, they can always
make in alias for "git pick".
- Ted
^ permalink raw reply
* Re: commit type
From: Samuel Lucas Vaz de Mello @ 2008-10-31 18:56 UTC (permalink / raw)
To: David Symonds; +Cc: 7rans, git
In-Reply-To: <ee77f5c20810311104m6044bf70r1d9d405fa04454e0@mail.gmail.com>
David Symonds wrote:
> On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire@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.
>
Also, you can use a hook to check that the commit message contains a valid "type".
- Samuel
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 18:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031184154.GV14786@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 3787 bytes --]
On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> How about this?
>
> http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
looks like a good start.
> > Second, if we want this to be a successful stuff, we all agree we must
> > let git be able to use it medium term. That means that when git-core is
> > experimenting with new interfaces, it will probably need to hook into
> > some more internal aspects of the library. This is a problem to solve
> > elegantly, linking git against a static library won't please a lot of
> > vendors and linux distributions, and exporting "private" symbols is a
> > sure way to see them being abused.
>
> Private symbols are a problem. On some systems we can use link
> editing to strip them out of the .so, but that isn't always going to
> work everywhere. I've outlined the idea of using double underscore
> to name private functions, and we can link-edit out '*__*' if the
> platform's linker supports it (e.g. GNU ld).
Well, I propose the following: we set-up on GNU-ld + gcc enabled systems
all what is needed to use symbol visibility, which isn't that intrusive,
and also rather easy given your GIT_EXPORT macro definition.
This way, people who care about portability across all libgit2 supported
platforms will have to align on the lowest common denominator, which
will not have any kind of private stuff available, so we're safe. And
GCC/GNU-ld enabled platforms cover most of the popular platforms (namely
linux and *BSD, I'm not sure about Macos dynlibs). Even win32 has kind
of what you need to do visibility I think.
IOW prehistoric systems will be have to cope with that because of Linux
(yeah, this is kind of deliciously backwards ;p).
No, my worry was rather wrt git core itself, I really think we _must_
make it link against libgit2 if we want libgit2 to stay current, but git
core will _very likely_ need the private stuff, and it _will_ be a
problem. I mean we cannot seriously so-name a library and show its guts
at the same time, and I'm unsure how to fix that problem. _that_ was my
actual question.
> > 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.
>
> Yea. We could try to do that. I don't know how far it will get us,
> but if we have to "steal" code we can rip a good part from JGit.
> Its BSD-like, but has that "icky Java smell" to it. :-)
>
> Before worrying about where we get implementation bits from I'm
> more interested in trying to get a consistent view of what our
> namespace looks like, and what our calling conventions are, so we
> have some sort of benchmark to measure APIs against as we add them
> to the implementation.
I'd say we should do both at the same time. Asking people if they would
agree to relicense code can be done in parallel. We could extract a list
of source files that we may need (my extraction included stuff that is
very unlikely to be useful like test-*.c that aren't useful, and some
that are already BSD I think), and see who it yields. It should be
possible to do a matrix source-file x people and see on a per-file basis
what they think.
If someone gives me the list of files we should consider (I'm not sure
about a good list right now) I could do the matrix at some fixed sha1
from git.git using git blame -C -M -M -w, and ask people see where it
leads us ?
--
·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 18:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Scott Chacon
In-Reply-To: <20081031174745.GA4058@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
>
> 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:
Agreed.
> * proper namespacing (e.g. OBJ_* looks like failure to me, it's a way
> too common prefix);
Fixed. Its now GIT_OBJ_*.
> * 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.
> And write that down _first_. It's not a lot of work, but it must be
> done. Working on a library really asks us to create something coherent
> for our users.
How about this?
http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
> Second, if we want this to be a successful stuff, we all agree we must
> let git be able to use it medium term. That means that when git-core is
> experimenting with new interfaces, it will probably need to hook into
> some more internal aspects of the library. This is a problem to solve
> elegantly, linking git against a static library won't please a lot of
> vendors and linux distributions, and exporting "private" symbols is a
> sure way to see them being abused.
Private symbols are a problem. On some systems we can use link
editing to strip them out of the .so, but that isn't always going to
work everywhere. I've outlined the idea of using double underscore
to name private functions, and we can link-edit out '*__*' if the
platform's linker supports it (e.g. GNU ld).
> 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.
Yea. We could try to do that. I don't know how far it will get us,
but if we have to "steal" code we can rip a good part from JGit.
Its BSD-like, but has that "icky Java smell" to it. :-)
Before worrying about where we get implementation bits from I'm
more interested in trying to get a consistent view of what our
namespace looks like, and what our calling conventions are, so we
have some sort of benchmark to measure APIs against as we add them
to the implementation.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Jeff King @ 2008-10-31 18:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Brian Gernhardt, Git List, Shawn O Pearce
In-Reply-To: <20081031183601.GB8464@artemis.corp>
On Fri, Oct 31, 2008 at 07:36:01PM +0100, Pierre Habouzit wrote:
> Set up a Debian autobuilder with dash as a /bin/sh (apt-get install
> dash, dpkg-reconfigure -plow dash and say 'yes'). You'll see those kind
> of problems arise immediately.
I don't need to; my development box is Debian with dash as /bin/sh. :)
> Dash is a POSIX compatible shell, with almost no extension added (in
> particular its echo has no -n option) which helps to find those kind of
> issues.
>
> It would help detecting git shell scripts that use bashism as well.
Agreed, and actually I found such a bashism (test ==) last week (though
of course it also broke on FreeBSD).
-Peff
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Pierre Habouzit @ 2008-10-31 18:36 UTC (permalink / raw)
To: Jeff King; +Cc: Brian Gernhardt, Git List, Shawn O Pearce
In-Reply-To: <20081031182456.GC3230@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
On Fri, Oct 31, 2008 at 06:24:56PM +0000, Jeff King wrote:
> On Fri, Oct 31, 2008 at 01:09:13AM -0400, Brian Gernhardt wrote:
>
> > Not all /bin/sh have a builtin echo that recognizes -n. Using printf
> > is far more portable.
> >
> > Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
> > the test scripts.
>
> Hmph. I think this is a good patch, and there is precedent in the past
> (20fa04ea, 2aad957, 9754563). But I am surprised this was not caught by
> our recent autobuilding project.
Set up a Debian autobuilder with dash as a /bin/sh (apt-get install
dash, dpkg-reconfigure -plow dash and say 'yes'). You'll see those kind
of problems arise immediately.
Dash is a POSIX compatible shell, with almost no extension added (in
particular its echo has no -n option) which helps to find those kind of
issues.
It would help detecting git shell scripts that use bashism as well.
--
·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] Avoid using non-portable `echo -n` in tests.
From: Jeff King @ 2008-10-31 18:24 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Shawn O Pearce
In-Reply-To: <1225429753-70109-1-git-send-email-benji@silverinsanity.com>
On Fri, Oct 31, 2008 at 01:09:13AM -0400, Brian Gernhardt wrote:
> Not all /bin/sh have a builtin echo that recognizes -n. Using printf
> is far more portable.
>
> Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
> the test scripts.
Hmph. I think this is a good patch, and there is precedent in the past
(20fa04ea, 2aad957, 9754563). But I am surprised this was not caught by
our recent autobuilding project.
However, it seems to work on FreeBSD (which makes it doubly weird that
it is broken on OS X). On Solaris, the /bin/sh is so horribly broken
that I have to use bash anyway. Commit 9754563 claims breakage on AIX,
but it looks like Mike is doing the AIX builds with bash.
So I guess we just need an OS X autobuild. ;)
> t/t4030-diff-textconv.sh | 2 +-
And of course this one was me, but I blame JSixt, whose test I just
mindlessly copied. ;)
-Peff
^ permalink raw reply
* Re: commit type
From: David Symonds @ 2008-10-31 18:04 UTC (permalink / raw)
To: 7rans; +Cc: git
In-Reply-To: <loom.20081031T174821-603@post.gmane.org>
On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire@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.
Dave.
^ permalink raw reply
* commit type
From: 7rans @ 2008-10-31 17:58 UTC (permalink / raw)
To: git
Hi--
I have a feature request.
I'd like to be a able to add a commit type to my commits, like 'major', 'minor',
'bug', etc. it would be useful in reviewing changes, especially when listing
changes for end-users to see, because then miscellaneous/administrative commits
could be omitted and only changes important to users listed.
Currently I achieve this by adding "[type]" to the end of my commit messages.
But of course that's less than optimal. I think being able to add a commit type
would be generally useful to everyone, and really has no downside becuase you do
not need to use it if you prefer not.
Thanks,
trans.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 17:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031170704.GU14786@spearce.org>
[-- Attachment #1.1: Type: text/plain, Size: 3900 bytes --]
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);
* 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.
* ...
And write that down _first_. It's not a lot of work, but it must be
done. Working on a library really asks us to create something coherent
for our users.
Second, if we want this to be a successful stuff, we all agree we must
let git be able to use it medium term. That means that when git-core is
experimenting with new interfaces, it will probably need to hook into
some more internal aspects of the library. This is a problem to solve
elegantly, linking git against a static library won't please a lot of
vendors and linux distributions, and exporting "private" symbols is a
sure way to see them being abused.
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.
For example, on parse-options.c, git blame yields:
git blame -C -C -M parse-options.c|cut -d\( -f2|cut -d2 -f1|sort|uniq -c
16 Alex Riesen
6 Jeff King
47 Johannes Schindelin
12 Junio C Hamano
19 Michele Ballabio
1 Nanako Shiraishi
1 Olivier Marin
395 Pierre Habouzit
Okay, arguably parse-options.c in libgit quite doesn't makes sense
(though it can help bringing some kind of uniformity to other git
ecosystem tools built on libgit but that's not the point I'm trying to
make), I'm sure this kind of pattern where it's likely to be easy to
relicense code happens to some source files. Nicolas already said I
think that he was okay with relicensing his work too e.g.
Maybe we could, in parallel to that, contact people who "own" code in
the core parts of git to ask them where they stand, and see if that can
free some bits of the code. Attached is the current owners of the non
builtin-* C, non header, code in git core, got using this on top of
next:
for i in *.c; do
case $i in
builtin-*)
continue;;
*)
git blame -C -C -M $i|cut -d\( -f2|cut -d2 -f1;;
esac
done
and doing sort | uniq -c | sort -n >owners on it is attached.
Interestingly, it yields around 200 contributors "only" but more
interestingly, only 41 people "own" more than 100 lines of code in
there, and 23 more if you add people with more than 50. IOW, it wouldn't
be absurd to mail those roughly 65 people ask them what they think of
relicensing their work (for those where it's needed because of current
GPL-ness of the code) and see what result it yields. Worst case we lost
like 2 or 3 weeks, best case scenario, we can reuse some bits of git to
reimplement some of the algorithms verbatim.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #1.2: owners --]
[-- Type: text/plain, Size: 4029 bytes --]
16818 Junio C Hamano
8892 Linus Torvalds
4978 Johannes Schindelin
3664 Shawn O. Pearce
2938 Nick Hengeveld
2857 Nicolas Pitre
2455 Daniel Barkalow
1660 Pierre Habouzit
1294 Adam Simpkins
1126 Mike McCormack
1110 René Scharfe
861 Jeff King
653 Lukas Sandström
564 Miklos Vajna
531 Johannes Sixt
495 Alex Riesen
400 Martin Koegler
332 Petr Baudis
310 Jon Loeliger
263 Timo Hirvonen
236 Brandon Casey
231 Lars Hjemli
221 Sergey Vlasov
200 H. Peter Anvin
181 Dmitry Potapov
165 Mike Hommey
163 Matthias Lederhofer
158 Robert Shearman
155 Andreas Ericsson
151 YOSHIFUJI Hideaki
147 Franck Bui-Huu
137 Christian Couder
127 Stephan Beyer
127 David Reiss
123 Paolo Bonzini
120 Steffen Prohaska
115 Scott R Parish
113 Bradford C. Smith
109 Kristian Høgsberg
105 Heikki Orsila
100 Andy Whitcroft
93 Jim Meyering
90 Wincent Colaiuta
90 Julian Phillips
87 Stephen R. van den Berg
85 Marco Costalba
82 David Rientjes
76 Sven Verdoolaege
75 Eric Wong
72 Edgar Toernig
71 Ramsay Allan Jones
69 Martin Waitz
68 Mark Wooding
68 Eric W. Biederman
67 Geert Bosch
64 Michal Ostrowski
64 David Kastrup
63 Theodore Ts'o
63 Alexandre Julliard
61 Brian Downing
59 Alexander Gavrilov
58 Andy Parkins
56 Jon Seymour
52 Carlos Rica
47 Sean Estabrooks
44 Dana L. How
43 J. Bruce Fields
41 Ping Yin
40 Florian Forster
38 Tilman Sauerbeck
38 Serge E. Hallyn
38 Kay Sievers
38 Jason Riedy
37 Dustin Sallings
35 Nguyễn Thái Ngọc Duy
35 Luiz Fernando N. Capitulino
35 Clemens Buchacher
34 Fredrik Kuivinen
33 Pavel Roskin
33 Lars Knoll
32 Josef Weidendorfer
32 Jonas Fonseca
30 Peter Eriksen
28 Jay Soffian
26 Grégoire Barbier
25 Adam Roben
24 Marius Storm-Olsen
24 Luben Tuikov
24 Jürgen Rühle
24 Bryan Larsen
24 Anders Melchiorsen
23 Pieter de Bie
23 Nanako Shiraishi
23 Michael S. Tsirkin
23 Brian Hetro
22 Paul Mackerras
22 Jens Axboe
20 Thomas Rast
19 Paul Collins
19 Matthias Kestenholz
19 Joachim Berdal Haga
19 David Woodhouse
18 Mark Levedahl
17 Michele Ballabio
15 Gerrit Pape
14 Sam Vilain
13 Olivier Marin
13 Adam Brewster
12 SZEDER Gábor
12 Kai Ruemmler
12 Govind Salinas
11 Sasha Khapyorsky
11 Raphael Zimmerer
11 Brian Gernhardt
10 Steven Grimm
10 Holger Eitzenberger
10 Dmitry V. Levin
10 Dennis Stosberg
10 Avery Pennarun
9 Willy Tarreau
9 Santi Béjar
9 Robin H. Johnson
9 James Bowes
9 Björn Steinbrink
8 Markus Amsler
8 Jonathan del Strother
8 Johan Herland
8 Chris Parsons
8 Boyd Lynn Gerber
7 Robin Rosenberg
7 Paul Serice
7 Matt Kraai
7 Jason McMullan
7 Frank Lichtenheld
7 Christopher Li
6 Qingning Huo
6 Han-Wen Nienhuys
6 David Soria Parra
6 Björn Engelmann
6 Ariel Badichi
5 Sam Ravnborg
5 Peter Hagervall
5 Paul T Darga
5 Michal Vitecek
5 James Bottomley
5 Dotan Barak
5 David S. Miller
5 André Goddard Rosa
4 Uwe Kleine-König
4 Teemu Likonen
4 Samuel Tardieu
4 Patrick Welche
4 Michael Spang
4 Matthieu Moy
4 Joey Hess
4 Finn Arne Gangstad
4 Dmitry Kakurin
4 Carl Worth
4 Arjen Laarhoven
3 Steven Drake
3 Matthew Ogilvie
3 Li Hong
3 Josh Triplett
3 Jakub Narebski
3 Eygene Ryabinkin
3 Brian Gerst
2 Tom Prince
2 Todd Zullinger
2 Shawn Bohrer
2 Matthias Urlichs
2 Martin Sivak
2 Krzysztof Kowalczyk
2 Kevin Ballard
2 Jan Harkes
2 Fernando J. Pereda
2 Eyvind Bernhardsen
2 Deskin Miller
2 Charles Bailey
2 Andrew Ruder
2 Amos Waterland
2 Alp Toker
2 Alexey Nezhdanov
1 Yann Dirson
1 Tuncer Ayaz
1 Tony Luck
1 Timo Sirainen
1 Thomas Harning
1 Thomas Glanzmann
1 Sverre Hvammen Johansen
1 Stephan Feder
1 Simon Hausmann
1 Salikh Zakirov
1 Ryan Anderson
1 Rutger Nijlunsing
1 Randal L. Schwartz
1 Peter Valdemar Mørch
1 Paul Eggert
1 Patrick Higgins
1 Mika Kukkonen
1 Matt Draisey
1 Marco Roeland
1 Lars Doelle
1 Jerald Fitzjerald
1 Jean-Luc Herren
1 Jan Andres
1 Ingo Molnar
1 David Symonds
1 David Meybohm
1 Darrin Thompson
1 Bryan Donlan
1 Brad Roberts
1 Blake Ramsdell
1 Benoit Sigoure
1 Adeodato Simó
[-- 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: Junio C Hamano @ 2008-10-31 17:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, schacon
In-Reply-To: <alpine.DEB.1.00.0810311753080.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> 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?
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pieter de Bie @ 2008-10-31 17:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Scott Chacon
In-Reply-To: <680C5F4A-C55A-45B1-99E0-A2A74B2DC634@ai.rug.nl>
On 31 okt 2008, at 18:28, Pieter de Bie wrote:
>> Source Code Clone URL:
>> http://www.spearce.org/projects/scm/libgit2/libgit2.git
>
> This 404's for me
Nevermind, it's only a clone url.. I'd expected a gitweb or so ;)
Sorry for the noise,
^ 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