* 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: [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: [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: 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] 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: 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: 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
* 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: 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
* 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: 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: [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: 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: 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: 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: 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
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