* Re: Standard cogito + patches: Changes to 'master'
From: Nico -telmich- Schottelius @ 2006-08-18 18:01 UTC (permalink / raw)
To: git
In-Reply-To: <20060818175454.8961.qmail@bruehe.schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
nico-linux-git@schottelius.org [Fri, Aug 18, 2006 at 05:54:54PM -0000]:
> [Commits]
For those who do not know where to find that branch:
Gitweb: http://unix.schottelius.org/cgi-bin/gitweb.cgi
Git-repo:http://unix.schottelius.org/git/cogito-original.git/
Nico
--
``...if there's one thing about Linux users, they're do-ers, not whiners.''
(A quotation of Andy Patrizio I completely agree with)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: Unresolved issues #3
From: Jon Loeliger @ 2006-08-18 17:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vpseyelcw.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-08-17 at 23:09, Junio C Hamano wrote:
> As everybody has probably noticed already, I am terrible at
> maintaining "the current issues" list. The most recent issue of
> this series was done when? Back on May 4th this year.
>
> Shame on me.
I continue to think you are doing a fabulous job nonetheless!
>
> Here is a list of topics in the recent git traffic that I feel
> inadequately addressed, in no particular order. I've commented
> on some of them to give people a feel for what my priorities
> are. Somebody might want to rehash the ones low on my priority
> list to conclusion with a concrete proposal if they cared about
> them enough.
I have another:
git-daemon virtualization so that consistent HTTP and
native git protocols can appear to use consistent URLs
even in the face of HTTP configurations aliasing them
to somewhere else on the filesystem and for multiple
virtually hosted domain names.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] cleans up builtin-mv
From: Josef Weidendorfer @ 2006-08-18 18:35 UTC (permalink / raw)
To: David Rientjes; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.63.0608180956100.29405@chino.corp.google.com>
On Friday 18 August 2006 19:07, David Rientjes wrote:
> It shouldn't have ever been a perl script, it should have been /bin/sh.
> Any shell implementation of this would be significantly faster than the
> current implementation.
Can you explain your reasoning in more detail?
C compiles to native code. Bash itself first has to
parse the script. How on earth can this be faster than native code?
I simply do not understand this discussion about implementation language,
especially in this case where most of the work is probably done changing
git's index (the add's and rm's of tree entries). Of course it could have
been done in /bin/sh, but it wasn't (it started as git-rename.perl).
The portability argument speaks for C, thus I agree with Dscho.
> > if (!bad &&
> > (length = strlen(source[i])) >= 0 &&
> > !strncmp(destination[i], source[i], length) &&
> > (destination[i][length] == 0 || destination[i][length] == '/'))
> >
> > construct. So, we assign the "length" variable only if we have to. And the
> > ">= 0" trick is a common one. I could have done
> >
>
> This is not a plausible justification _at all_.
Hmm... I suppose Dscho's argument was that this "... >=0" is a standard way
to code an assignment inside of an expression.
Josef
^ permalink raw reply
* Re: [PATCH] cleans up builtin-mv
From: David Rientjes @ 2006-08-18 19:01 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Johannes Schindelin, git
In-Reply-To: <200608182035.47208.Josef.Weidendorfer@gmx.de>
On Fri, 18 Aug 2006, Josef Weidendorfer wrote:
> Can you explain your reasoning in more detail?
> C compiles to native code. Bash itself first has to
> parse the script. How on earth can this be faster than native code?
>
> I simply do not understand this discussion about implementation language,
> especially in this case where most of the work is probably done changing
> git's index (the add's and rm's of tree entries). Of course it could have
> been done in /bin/sh, but it wasn't (it started as git-rename.perl).
>
It's not faster than native code, it's faster than the current
implementation of builtin-mv. And when you're working with terabytes of
data like I am, I would prefer to use something fast.
> Hmm... I suppose Dscho's argument was that this "... >=0" is a standard way
> to code an assignment inside of an expression.
>
That argument is unjustified since the only advantage of putting it in an
expression is to not evaluate it if the lstat failed (and not fail by
means of ENOENT because copy_pathspec guarantees all results have strlen >
0). So "length" is set unnecessarily only if lstat fails which should
never happen if copy_pathspec does it's job with correct arguments. I'm
willing to sacrifice that if the _working_ case is faster (and
significantly faster) especially since this is an iteration and is
directly tied to the command's speed.
The comparison to 0 simply creates a cmpl $0, x(%ebp) that will always be
true and a jump to a label that never needed to exist.
Likewise, the additional declaration and initilization of a completely
redundant case call to strlen slows us down FOR EVERY ITERATION OF THE
MOVE:
movl %eax, x(%ebp)
movl (x*2)(%ebp), %eax
movl $-1, %ecx
movl %eax, (x*4)(%ebp)
movb %0, %al
cld
movl (x*4)(%ebp), %edi
repnz
scasb
movl %ecx, %eax
notl %eax
decl %eax
And then repeat that same call again because of its miscall later on when
it's already been assigned to a variable.
David
^ permalink raw reply
* Re: [PATCH] cleans up builtin-mv
From: Junio C Hamano @ 2006-08-18 19:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, David Rientjes
In-Reply-To: <Pine.LNX.4.63.0608181137000.28360@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> What you cleverly did not mention: It was inside a
>
> if (!bad &&
> (length = strlen(source[i])) >= 0 &&
> !strncmp(destination[i], source[i], length) &&
> (destination[i][length] == 0 || destination[i][length] == '/'))
>
> construct. So, we assign the "length" variable only if we have to. And the
> ">= 0" trick is a common one. I could have done
>
> !strncmp(destination[i], source[i], (length = strlen(source[i])))
>
> but even I find that ugly.
I usually side with you but on this I can't.
There are 2 ways to generate branch instructions in C.
- compound statements specifically designed for expressing
control structure: if () ... else ..., for (), while (),
switch (), etc.
- expressions using conditional operators or logical operators
that short circuit: ... ? ... : ..., ... && ... || ...
The latter form may still be readable even with simple side
effects inside its terms, but "(l = strlen(s)) >= 0" is done
solely for the side effect, and its computed value does not have
anything to do with the logical operation &&.
THIS IS UGLY. And do not want to live in a world where this
ugliness is a "common one", as you put it.
And this avoiding one call to strlen(source[i]) is unnecessary
even as an optimization -- you end up calling strlen() on it
later in the code anyway, as David points out.
I think this part is far easier to read if you did it like this:
length = strlen(source[i]);
if (lstat(source[i], &st) < 0)
bad = "bad source";
else if (!strncmp(destination[i], source[i], length) &&
(destination[i][length] == 0 ||
destination[i][length] == '/'))
bad = "can not move directory into itself";
if (S_ISDIR(st.st_mode)) {
...
Note that the above is an absolute minimum rewrite. Other
things I noticed are:
- source[i] and destination[i] are referenced all the time; the
code would be easer to read if you had something like this
upfront:
/* Checking */
for (i = 0; i < count; i++) {
const char *bad = NULL;
const char *src = source[i];
const char *dst = destination[i];
int srclen = strlen(src);
int dstlen = strlen(dst);
You might end up not using dstlen in some cases, but I think
this would be far easier to read. Micro-optimizing by saying
"this is used only in this branch of this later if()
statement but in that case it is always set in that branch of
that earlier if() statement" makes unmaintainably confusing
code.
- I do not think you need "const char *dir, *dest_dir" inside
the "source is directory" branch; I would just use src and dst
consistently;
- You muck with dest_dir by calling add_slash(dest_dir) but
call prefix_path() with dst_len you computed earlier;
prefix_path() may know what to do, but is this intended?
^ permalink raw reply
* Re: [PATCH] gitweb: Support for snapshot
From: Luben Tuikov @ 2006-08-18 19:51 UTC (permalink / raw)
To: Aneesh Kumar K.V, git
In-Reply-To: <44E54AC6.9010600@gmail.com>
--- "Aneesh Kumar K.V" <aneesh.kumar@gmail.com> wrote:
> This adds snapshort support in gitweb. To enable one need to
> set gitweb.snapshot = true in the config file.
Could you use bzip2? It generates smaller files (better compression),
which is a good thing when downloading over a network.
Luben
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> ---
> gitweb/gitweb.perl | 41 +++++++++++++++++++++++++++++++++++++----
> 1 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 04282fa..d6f96a3 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -15,6 +15,7 @@ use CGI::Carp qw(fatalsToBrowser);
> use Encode;
> use Fcntl ':mode';
> use File::Find qw();
> +use File::Basename qw(basename);
> binmode STDOUT, ':utf8';
>
> our $cgi = new CGI;
> @@ -175,6 +176,7 @@ my %actions = (
> "tag" => \&git_tag,
> "tags" => \&git_tags,
> "tree" => \&git_tree,
> + "snapshot" => \&git_snapshot,
> );
>
> $action = 'summary' if (!defined($action));
> @@ -1320,6 +1322,7 @@ sub git_difftree_body {
> sub git_shortlog_body {
> # uses global variable $project
> my ($revlist, $from, $to, $refs, $extra) = @_;
> + my $have_snapshot = git_get_project_config_bool('snapshot');
> $from = 0 unless defined $from;
> $to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
>
> @@ -1344,8 +1347,11 @@ sub git_shortlog_body {
> print "</td>\n" .
> "<td class=\"link\">" .
> $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
> - $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
> - "</td>\n" .
> + $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff");
> + if ($have_snapshot) {
> + print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
> + }
> + print "</td>\n" .
> "</tr>\n";
> }
> if (defined $extra) {
> @@ -2112,6 +2118,29 @@ sub git_tree {
> git_footer_html();
> }
>
> +sub git_snapshot {
> +
> + if (!defined $hash) {
> + $hash = git_get_head_hash($project);
> + }
> +
> + my $filename = basename($project) . "-$hash.tar.gz";
> +
> + print $cgi->header(-type => 'application/x-tar',
> + -content-encoding => 'x-gzip',
> + '-content-disposition' => "inline; filename=\"$filename\"",
> + -status => '200 OK');
> +
> + open my $fd, "-|", "$GIT tar-tree $hash \'$project\' | gzip" or
> + die_error(undef, "Execute git-tar-tree failed.");
> + binmode STDOUT, ':raw';
> + print <$fd>;
> + binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
> + close $fd;
> +
> +
> +}
> +
> sub git_log {
> my $head = git_get_head_hash($project);
> if (!defined $hash) {
> @@ -2206,6 +2235,7 @@ sub git_commit {
> }
> my $refs = git_get_references();
> my $ref = format_ref_marker($refs, $co{'id'});
> + my $have_snapshot = git_get_project_config_bool('snapshot');
> my $formats_nav = '';
> if (defined $file_name && defined $co{'parent'}) {
> my $parent = $co{'parent'};
> @@ -2241,8 +2271,11 @@ sub git_commit {
> "<td class=\"sha1\">" .
> $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash), class =>
> "list"}, $co{'tree'}) .
> "</td>" .
> - "<td class=\"link\">" . $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'},
> hash_base=>$hash)}, "tree") .
> - "</td>" .
> + "<td class=\"link\">" . $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'},
> hash_base=>$hash)}, "tree");
> + if ($have_snapshot) {
> + print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$hash)}, "snapshot");
> + }
> + print "</td>" .
> "</tr>\n";
> my $parents = $co{'parents'};
> foreach my $par (@$parents) {
> --
> 1.4.2.rc1.g83e1-dirty
>
>
^ permalink raw reply
* Re: [PATCH] gitweb: Support for snapshot
From: Timo Hirvonen @ 2006-08-18 20:05 UTC (permalink / raw)
To: Luben Tuikov; +Cc: aneesh.kumar, git
In-Reply-To: <20060818195148.66411.qmail@web31807.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
> --- "Aneesh Kumar K.V" <aneesh.kumar@gmail.com> wrote:
> > This adds snapshort support in gitweb. To enable one need to
> > set gitweb.snapshot = true in the config file.
>
> Could you use bzip2? It generates smaller files (better compression),
> which is a good thing when downloading over a network.
bzip2 is much slower than gzip. Often just uncompressing .tar.bz2 takes
more time than downloading bigger .tar.gz file. For small projects it
doesn't matter which one you use.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: 2 build issues
From: Randy.Dunlap @ 2006-08-18 20:14 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060815061056.GB4543@coredump.intra.peff.net>
On Tue, 15 Aug 2006 02:10:56 -0400 Jeff King wrote:
> On Mon, Aug 14, 2006 at 12:11:56PM -0700, Randy.Dunlap wrote:
>
> > xmlto -m callouts.xsl man git-add.xml
> > I/O error : Attempt to load network entity
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
>
> It looks like your docbook installation is broken. You should have
> an xml catalog file that translates the url to a local file
> reference for the docbook stylesheet. Can you verify the integrity
> of / reinstall your docbook package?
You got it. Thanks.
---
~Randy
^ permalink raw reply
* Re: [PATCH] gitweb: use common parameter parsing and generation for "o", too.
From: Martin Waitz @ 2006-08-18 20:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200608172134.38751.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]
hoi :)
On Thu, Aug 17, 2006 at 09:34:38PM +0200, Jakub Narebski wrote:
> > Perhaps we can agree that only the validation should be coupled with the
> > actual user? E.g. use normal validate_input() for it and then check
> > for actual values inside git_project_list (which is already done now).
>
> The validate_input() function has too generic name and is too widely used:
> it should be split into validate_ref() and validate_path(); perhaps "o"
> should be validate with $order =~ m/^[a-zA-Z]$/
agreed.
> But I was thinking about moving parameter parsing to the "action" functions
> which use them, the opposite of what you want to do...
but only short-term.
I think we both agree on the same target:
we need some simple to pass parameters to a function which should only
be called if the user clicks on a specific link.
Now lets talk about the interface to do this.
We need one interface for generating the URL (stub in RPC talk)
and one for calling the function once the link is clicked (skeleton).
We now have the href() function which is not so bad for the stub side.
We now need a nice generic skeleton.
Perhaps introduce a new function which is used to access the parameters?
This new function could check the URL or CGI->param or whatever and then
return the requested value.
Then the action functions could get all parameters they need, validate
them themselves and then act on them.
This would suit my "break out parameter parsing from actions" and your
"validate parameters in the action function".
(And I really interpret your sentence in such a way that you only want
to move the _validation_, not the actual parsing (which is done inside
CGI->param at the moment.)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] adding support for md5
From: David Rientjes @ 2006-08-18 20:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608181209210.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 18 Aug 2006, Johannes Schindelin wrote:
> Make it a config variable, too, right?
>
Sure. The default hash function can be a config variable so that all
projects started with init-db will default to a specific hash. Other
projects may still be started with something like init-db -md5.
> 1. they could be faster to calculate,
> 2. they could reduce clashes, and related to that,
> 3. it is possible that some day SHA1 is broken, i.e. that there is an
> algorithm to generate a different text for a given hash.
>
> As for 2 and 3, it seems MD5 is equivalent, since another sort of attacks
> was already successful on both SHA1 and MD5: generating two different
> texts with the same hash.
>
Correct; performance was my main motivation. sha1 is obviously the
securest algorithm among the two choices, but there are more steps
involved in the hash than md5 (sha1 uses 80 and md5 uses 64) and sha1 is
160-bit compared to the 128-bit md5. One paper I read from the
Information Technology Journal stated that sha1 is 25% slower than md5
precisely for these reasons.
> However, you should know that there is _no way_ to use both hashes on the
> same project. Yes, you could rewrite the history, trying to convert also
> the hashes in the commit objects, but people actually started relying on
> naming commits with the short-SHA1.
>
I don't foresee changing a hash on a project (and thus rewriting the
history) to be something that anybody would want to do. As I said in the
email that started this thread, it would be configurable at runtime on
init-db.
> I think it would be a nice thing to play through (for example, to find
> out how much impact the hash calculation has on the overall performance
> of git), but I doubt it will ever come to real use.
>
Again, when working with an enormous amount of data, this could be a
considerable speedup. A terabyte is _big_.
David
^ permalink raw reply
* Re: something broken just now on git-pull from openbsd to OSX
From: Randal L. Schwartz @ 2006-08-18 16:22 UTC (permalink / raw)
To: git
In-Reply-To: <86lkpmkod3.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I just updated my openbsd's GIT to 1.4.2.g55c3, and now my
Randal> git-fetch from there to my OSX fails with a fatal error almost immediately.
Randal> What just changed? What can I check?
Randal> git-fetch from other repositories to OSX seems to work fine.
Randal> Ahh, it might even be a corrupt repository... here's what
Randal> a local git-clone shows:
Randal> git-clone ~/Git/stonehenge.git
Randal> remote: Generating pack...
Randal> remote: Done counting 2610 objects.
Randal> remote: Deltifying 2610 objects.
Randal> 100% (2610/2610) done
Randal> remote: Total 2610, written 2610 (delta 1244), reused 2610 (delta 1244)
Randal> error: git-fetch-pack: unable to read from git-index-pack
Randal> error: git-index-pack died of signal 11
Randal> fetch-pack from '/home/merlyn/Git/stonehenge.git/.git' failed.
Randal> What do you want me to try to help diagnose this?
And even more info:
$ git-repack -a -d
Generating pack...
Done counting 2610 objects.
Deltifying 2610 objects.
100% (2610/2610) done
Writing 2610 objects.
100% (2610/2610) done
Total 2610, written 2610 (delta 1244), reused 2610 (delta 1244)
Pack pack-3cd61a256bd8736b13b0356aafff016260c22b80 created.
$ git-repack -a -d -f
Generating pack...
Done counting 2610 objects.
Deltifying 2610 objects.
Segmentation fault
Oops! That's not good.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: something broken just now on git-pull from openbsd to OSX
From: Junio C Hamano @ 2006-08-18 21:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86hd0ako8h.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> And even more info:
>
> $ git-repack -a -d
> Generating pack...
> Done counting 2610 objects.
> Deltifying 2610 objects.
> 100% (2610/2610) done
> Writing 2610 objects.
> 100% (2610/2610) done
> Total 2610, written 2610 (delta 1244), reused 2610 (delta 1244)
> Pack pack-3cd61a256bd8736b13b0356aafff016260c22b80 created.
> $ git-repack -a -d -f
> Generating pack...
> Done counting 2610 objects.
> Deltifying 2610 objects.
> Segmentation fault
>
> Oops! That's not good.
Indeed it is not good.
First we would need to see who is dying.
git-repack -a -d -f does:
- list all the objects that need to be packed by running
git rev-list --objects --all
- piping that to pack-objects
- after that remove old ones (because -d is given)
I am suspecting it is either rev-list or pack-objects, but let's
isolate which first.
git-rev-list --objects --all >/var/tmp/revlist.out
Does this die? If not
git-pack-objects pack </var/tmp/revlist.out
does this die?
Once you isolate which, can you bisect to see where it broke in
recent history (assuming it worked ever on OSX)?
^ permalink raw reply
* Re: [RFC] adding support for md5
From: Jon Smirl @ 2006-08-18 21:52 UTC (permalink / raw)
To: David Rientjes; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608172259280.25827@chino.corp.google.com>
On 8/18/06, David Rientjes <rientjes@google.com> wrote:
> I'd like to solicit some comments about implementing support for md5 as a
> hash function that could be determined at runtime by the user during a
> project init-db. md5, which I implemented as a configurable option in my
> own tree, is a 128-bit hash that is slightly more recognized than sha1.
> Likewise, it is also available in openssl/md5.h just as sha1 is available
> through a library in openssl/sha1.h. My patch to move the hash name
> comparison was a step in this direction in isolating many of the
> particulars of hash-specific dependencies.
If I have two repositories each with 100M objects in them and I merge
them, what is the probability of a object id collision with MD5 (128b)
versus SHA1 (160b)?
This is not that far fetched. I know of at least four repositories
with over 1M objects in them today.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Recover from a bad push in StGit
From: Robin Rosenberg @ 2006-08-18 22:30 UTC (permalink / raw)
To: git
Hi,
I recently did some reordering of patches and goofed up (not totally, but
anyway). I pushed a number of patches and forgot one in the middle resulting
in a merge conflict. Pop won't work since I have local changes from the
conflict and I don't want to resolve the conflict either since I didn't mean
to push the patch at that point.
Is there a simple way of undoing a bad push?
In this case I had a fresh export do help me out so I could just delete the
patches and re-import them again, but what if I didn't?
-- robin
^ permalink raw reply
* git clone dies (large git repository)
From: Troy Telford @ 2006-08-18 22:42 UTC (permalink / raw)
To: git
I've got a git repository I use to manage a set of RPMs. It's got history
stretching back for years, and imported nicely into git. Since it's used
to create RPMs, the repository has a structure similar to this:
.
|--README
|-- foo
| |--SOURCES
| | |--foo.tar.bz2
| | `--foo-build.patch
| `--SPECS
| `--foo.spec
`-- bar
|--SOURCES
| |--bar.tar.bz2
| `--bar-build.patch
`--SPECS
`--bar.spec
The source tarballs are updated when there's a new version of the
software; I don't need to worry about changes that are /inside/ the
tarball-- just that the tarball itself has changed. As you can imagine, a
fair amount of the 'stuff' in the repository are these binary tarballs.
The total repository size (ie. the '.git' folder): 4GB
I have only one complaint (and I can work around it anyway): I can't 'git
clone' the repository.
if I run:
git clone git://my.server.net/git/rpms
I get the following output:
remote: Generating pack...
remote: Done counting 20971 objects.
remote: Deltifying 20971 objects.
remote: 100% (20971/20971) done
3707.885MB (21657 kB/s)
remote: Total 20971, written 20971 (delta 9604), reused 20971 (delta 9604)
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died of signal 11
fetch-pack from 'git://my.server.net/git/rpms' failed.
It's interesting to note that during the pack file transfer, it stops
incrementing at ~3700 MB; the pack file is 4.0 GB. So either 300MB isn't
being transferred, or it's just not updating the display for the last few
hundred megs.
My workaround is to just use 'rsync' to copy the data (although scp works
too), then checkout the working copy. After that, fetch/pull and push
work fine.
The behavior is consistent with git v1.4.1 and v1.4.2, on SLES 9, SLES 10,
RHEL 4, and Gentoo.
It is also consistent if I clone via the git daemon, or the ssh protocol
('git clone server:/path/to/repo')
I originally had everything as loose objects. I then ran 'git-repack -d'
on occasion, so I had a combination of a large pack file, smaller pack
files, and loose objects. Finally, I tried 'git repack -a -d' and
consolidated it all into a single 4GB pack file. It didn't seem to make
much difference in the output.
Am I bumping some sort of limitation within git, or have I uncovered a bug?
--
Troy Telford
^ permalink raw reply
* Re: Recover from a bad push in StGit
From: Robin Rosenberg @ 2006-08-19 0:11 UTC (permalink / raw)
To: git
In-Reply-To: <200608190030.47257.robin.rosenberg.lists@dewire.com>
lördag 19 augusti 2006 00:30 skrev Robin Rosenberg:
> Hi,
>
> I recently did some reordering of patches and goofed up (not totally, but
> anyway). I pushed a number of patches and forgot one in the middle
> resulting in a merge conflict. Pop won't work since I have local changes
> from the conflict and I don't want to resolve the conflict either since I
> didn't mean to push the patch at that point.
>
> Is there a simple way of undoing a bad push?
It was so simple
stg status --reset;stg pop
does the job. Sorry about the noise.
>
> In this case I had a fresh export do help me out so I could just delete the
> patches and re-import them again, but what if I didn't?
>
-- robin
^ permalink raw reply
* Delight in Introducing a great product which will make you a better, more confident man!
From: Dana @ 2006-08-19 0:45 UTC (permalink / raw)
To: git
Get the freshest
Introducing a great product which will make you a better, more confident man! Experience noticeable and stable results in your pants - just weeks of usage!
You certainly thought about women worshipping you because of your size and performance. Try to imagine your totally new life free from size fears, lack of confidence and with terrific success among females. Take a look: http://www.ilmestelv.com/gal/ms/
You won't increase your most important muscle in gyms - so this is what you have to try!
When dog hungry he ah nyam calabash. When I turned myself over to God, i took my life out the hands of an idiot Even a clock that does not work is right twice a day Adversity Makes Strange Bedfellows
^ permalink raw reply
* Re: [PATCH] cleans up builtin-mv
From: Johannes Schindelin @ 2006-08-19 1:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqqh96v2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 18 Aug 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > What you cleverly did not mention: It was inside a
> >
> > if (!bad &&
> > (length = strlen(source[i])) >= 0 &&
> > !strncmp(destination[i], source[i], length) &&
> > (destination[i][length] == 0 || destination[i][length] == '/'))
> >
> > construct. So, we assign the "length" variable only if we have to. And the
> > ">= 0" trick is a common one. I could have done
> >
> > !strncmp(destination[i], source[i], (length = strlen(source[i])))
> >
> > but even I find that ugly.
>
> I usually side with you but on this I can't.
>
> There are 2 ways to generate branch instructions in C.
>
> - compound statements specifically designed for expressing
> control structure: if () ... else ..., for (), while (),
> switch (), etc.
>
> - expressions using conditional operators or logical operators
> that short circuit: ... ? ... : ..., ... && ... || ...
>
> The latter form may still be readable even with simple side
> effects inside its terms, but "(l = strlen(s)) >= 0" is done
> solely for the side effect, and its computed value does not have
> anything to do with the logical operation &&.
>
> THIS IS UGLY. And do not want to live in a world where this
> ugliness is a "common one", as you put it.
Okay. Probably the explanation is: I do not use git-mv myself, but only
got annoyed enough by a failing t7001 to rewrite it.
> And this avoiding one call to strlen(source[i]) is unnecessary
> even as an optimization -- you end up calling strlen() on it
> later in the code anyway, as David points out.
>
> I think this part is far easier to read if you did it like this:
>
> length = strlen(source[i]);
> if (lstat(source[i], &st) < 0)
> bad = "bad source";
> else if (!strncmp(destination[i], source[i], length) &&
> (destination[i][length] == 0 ||
> destination[i][length] == '/'))
> bad = "can not move directory into itself";
>
> if (S_ISDIR(st.st_mode)) {
> ...
>
> Note that the above is an absolute minimum rewrite. Other
> things I noticed are:
>
> - source[i] and destination[i] are referenced all the time; the
> code would be easer to read if you had something like this
> upfront:
>
> /* Checking */
> for (i = 0; i < count; i++) {
> const char *bad = NULL;
> const char *src = source[i];
> const char *dst = destination[i];
> int srclen = strlen(src);
> int dstlen = strlen(dst);
>
> You might end up not using dstlen in some cases, but I think
> this would be far easier to read. Micro-optimizing by saying
> "this is used only in this branch of this later if()
> statement but in that case it is always set in that branch of
> that earlier if() statement" makes unmaintainably confusing
> code.
>
> - I do not think you need "const char *dir, *dest_dir" inside
> the "source is directory" branch; I would just use src and dst
> consistently;
These changes would make the source more readable, yes.
> - You muck with dest_dir by calling add_slash(dest_dir) but
> call prefix_path() with dst_len you computed earlier;
> prefix_path() may know what to do, but is this intended?
That is probably a late night oversight.
If noone else is faster, I will do the requested changes tomorrow.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] adding support for md5
From: Johannes Schindelin @ 2006-08-19 2:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608181452x65ca937aqbfde55caa98ff6da@mail.gmail.com>
Hi,
On Fri, 18 Aug 2006, Jon Smirl wrote:
> If I have two repositories each with 100M objects in them and I merge
> them, what is the probability of a object id collision with MD5 (128b)
> versus SHA1 (160b)?
Assuming a uniform distribution of the hashes over our data, this is the
birthday problem:
http://mathworld.wolfram.com/BirthdayProblem.html
(In short, given a number of days in the year, how many people do I need
to pick randomly until at least two of them have the same birthday?)
In our case, we want to know how many objects we need in order to probably
have a clash in 2^128 (approx. 3.4e38) and 2^160 (approx. 1.5e48) hashes,
respectively.
Mathworld tells us that a good approximation of the probability is
p = 1 - (1-n/(2d))^(n-1)
where n is the number of objects, and d is the total number of hashes. If
you have 100M = 1e5 objects, you probably want the probability of a clash
below 1/1e5 = 1e-5, so let's take 1e-10. Assuming n is way lower than d,
we can approximate
p = 1 - (1 - (n - 1 over 1) * n/(2d)) = n(n-1)/2d
and therefore (approximately)
n = sqrt(2pd)
which amounts to 2.6e14 in the case of a 128-bit hash, and 1.7e19 in the
case of a 160-bit hash, both well beyond your 100M objects. BTW the
addressable space of a 64-bit processor is about 1.9e19.
If you want to know the probability of a clash, you can use the same
approximation:
For 100M objects: p = 1.5e-59 for 128-bit, and p = 3.3e-69 for 160-bit.
This is so low as to be incomprehensible.
Remember that all these approximations are really crude, so do not rely on
the precise numbers. But they'll give you good ballpark figures (if I did
not make a mistake...).
Hth,
Dscho
^ permalink raw reply
* Re: [RFC] adding support for md5
From: linux @ 2006-08-19 3:19 UTC (permalink / raw)
To: rientjes; +Cc: git
This is a Very Dumb Idea.
I normally try to be polite, but this concept is particularly
deserving of scorn.
The idea that more choice is a good thing is sometimes seductive, but when
it comes to standards, that's not a good idea. It's like the famous joke
told about the dumb inhabitants of your favorite ethnic region: they're
going to try driving on the other side of the road. Starting next month,
all the cars will drive on the other side. If that goes well, the month
after they'll add trucks and buses.
If some disaster arose that required Git to change hash functions,
it would be possible to build a conversion utility, although all the
signatures in tag objects would break; you'd have to regenerate them, too.
But this is an all-or-nothing change. Trying to support *multiple*
simultaneous hash functions is a mess.
Git depends very fundamentally on identical objects having identical
hashes. The in-memory merge depends on it. The network protocol
depends on it. Various kludges can be imagined to handle blob objects
with multiple names, but tree objects quickly become unworkable.
Let's break down the solutions. There are basically four classes,
depending on
1) whether objects are stored in the database indexed by both hashes,
or just one, and
2) Whether pointers to objects include both hashes, or just one.
If you include both hashes everywhere, then you've just built
a larger hash function that's the concatenation of SHA-1 and MD5,
and while it works sanely, it just makes the object IDs even
bigger, and there are obviously no speed benefts. But this is
the most reasonable alternative.
If pointers include both hashes, but objects are indexed by only one,
then to find an object by pointer requires two lookups, and you still
need to hash every blob twice when committing get the values to
put in the tree objects. So obviosuly no faster than the first option.
Okay, so pointers are only one hash. If they were always the same hash,
the second hash would be utterly pointless, so we're assuming the
database contains a mix.
If objects are indexed by both hashes, then you can hash new blobs once
to check to see if they're already in the database, but if they're not,
you have to hash again with the another algorithm.
On the other hand, if you index by only one, then every object being
checked to see if it's already in the database needs to be hashed twice
so it can be looked up twice. What were the claimed speed gains?
But more to the point, any system which stores one arbitrary hash as
a pointer makes the the tree object created to describe a directory no
longer unique, which results in its hash being fundamentally non-unique,
which cascades all the way up to the commit object.
So you can get silly things like the need for a merge commit to
record the merge of trees that are actually identical.
Just a big mess.
^ permalink raw reply
* Re: Unresolved issues #3
From: A Large Angry SCM @ 2006-08-19 4:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0608181119410.11359@localhost.localdomain>
Nicolas Pitre wrote:
> On Fri, 18 Aug 2006, A Large Angry SCM wrote:
>
>> Nicolas Pitre wrote:
>>> On Thu, 17 Aug 2006, A Large Angry SCM wrote:
>> ...
>>>> 1) I disagree with Nico's assessment that, other than his, there can not
>>>> exist any type 2 packs that have bit 6 set to mean copy from result.
>>> Care to explain why?
>>>
>>> Since this code is mine I can tell you that no official GIT version ever
>> ^^^^^^^^^^^^^^^^^^^^^^^
>>> produced such a pack. The code to make use of that bit was quite
>>> involving and the end result wasn't great at all so I never published
>>> said code. This is also why current GIT accepts both pack version 2 and
>>> 3 without any distinction using the same code in patch-delta.c on the
>>> basis that no version 2 packs ever used that bit.
>> That doesn't prove the non-existence of other code to do it.
>
> So? If the official and primary code for GIT doesn't support it, what
> is the point? I'm telling you that if such packs exist they will simply
> barf with all official GIT releases later than v1.1.6 making your
> argument pointless.
>
> I don't mind you documenting that historic intent for a bit that was
> never officially used, but at least let's document it right.
Historic fact. Between Thu May 19 08:56:22 2005 and Thu Feb 9 21:06:38
2006 bit 6 of the first byte of a delta hunk was interpreted to mean
that the source of the copy was the result buffer. From Thu May 19
08:56:22 2005 on, the code to decode delta hunks in type 2 packs was
available to everyone and anyone interested could make a pack encoder
that would create packs that the core Git code would correctly read. The
commit of Thu Feb 9 21:06:38 2006, d60fc, actually introduced a bug
that would treat valid type 2 packs as invalid.
Since there was not any documentation that declared the bit as reserved,
the code was the documentation and it specified that bit 6 of the first
byte of a delta hunk was to be interpreted as meaning the the copy
source in the result buffer. The code did not and does not document intent.
^ permalink raw reply
* Re: [PATCH] gitweb: Support for snapshot
From: Aneesh Kumar @ 2006-08-19 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git, jakub narebski
In-Reply-To: <7v64gp7prk.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On 8/19/06, Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > --- "Aneesh Kumar K.V" <aneesh.kumar@gmail.com> wrote:
> >> This adds snapshort support in gitweb. To enable one need to
> >> set gitweb.snapshot = true in the config file.
> >
> > Could you use bzip2? It generates smaller files (better compression),
> > which is a good thing when downloading over a network.
>
> Because bzip2 is heavier on the server than gzip is (and gzip is
> heavier than "gzip -1" is), there obviously is a trade-off. We
> would want it to be configurable just like blame and snapshot
> itself.
>
> Maybe:
>
> config.snapshot = no | yes | gzip | bzip2 ...
>
> By the way, I think it is a mistake to use only $GIT_DIR/config
> to control these features.
>
I have coded this at
What should be the content-encoding in this case x-$snapshot ?
This is the untested diff that i have. Is this what we are looking for ?
-aneesh
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gitweb.diff --]
[-- Type: text/x-patch; name="gitweb.diff", Size: 2484 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f8d1036..6ad3141 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -67,6 +67,15 @@ # file to use for guessing MIME types be
# (relative to the current git repository)
our $mimetypes_file = undef;
+# don't enable snapshot support by default
+# possible values are no|gzip|bzip2|
+our $snapshot = "no";
+
+# this indicate whether the snapshot support can be overridden
+# by a project specific config.
+# possible values are yes|no
+our $snapshot_override = "no";
+
our $GITWEB_CONFIG = $ENV{'GITWEB_CONFIG'} || "++GITWEB_CONFIG++";
require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
@@ -1397,7 +1406,7 @@ sub git_difftree_body {
sub git_shortlog_body {
# uses global variable $project
my ($revlist, $from, $to, $refs, $extra) = @_;
- my $have_snapshot = git_get_project_config_bool('snapshot');
+ my ($have_snapshot, $snapshot_comp) = git_get_project_snapshot_config();
$from = 0 unless defined $from;
$to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
@@ -2200,13 +2209,14 @@ sub git_snapshot {
}
my $filename = basename($project) . "-$hash.tar.gz";
+ my ($have_snapshot, $snapshot_comp) = git_get_project_snapshot_config();
print $cgi->header(-type => 'application/x-tar',
- -content-encoding => 'x-gzip',
+ -content-encoding => "x-$snapshot_comp",
'-content-disposition' => "inline; filename=\"$filename\"",
-status => '200 OK');
- open my $fd, "-|", "$GIT tar-tree $hash \'$project\' | gzip" or
+ open my $fd, "-|", "$GIT tar-tree $hash \'$project\' | $snapshot_comp" or
die_error(undef, "Execute git-tar-tree failed.");
binmode STDOUT, ':raw';
print <$fd>;
@@ -2215,6 +2225,27 @@ sub git_snapshot {
}
+sub git_get_project_snapshot_config()
+{
+ my $snap;
+
+ if ($snapshot =~ m/no/) {
+ return (0, undef);
+ }
+
+ if ($snapshot_override =~ m/no/) {
+ return (1, $snapshot);
+ }
+
+ $snap = git_get_project_config('snapshot');
+
+ if ($snap and $snap =~ m/no/) {
+ return (0, undef);
+ }
+ return (1, $snap);
+}
+
+}
sub git_log {
my $head = git_get_head_hash($project);
@@ -2293,7 +2324,7 @@ sub git_commit {
}
my $refs = git_get_references();
my $ref = format_ref_marker($refs, $co{'id'});
- my $have_snapshot = git_get_project_config_bool('snapshot');
+ my ($have_snapshot, $snapshot_comp) = git_get_project_snapshot_config();
my $formats_nav = '';
if (defined $file_name && defined $co{'parent'}) {
my $parent = $co{'parent'};
^ permalink raw reply related
* Relax with This costs much less than a luxury car - but makes you a lot more confident and attractive.
From: Trudy @ 2006-08-19 10:27 UTC (permalink / raw)
To: glenn
Latest stuff
Had doubts that these things really work? Check this out and join the thousands of happy men! You will be pleased with the surprisingly great results after weeks, or even days.
Some intimate experiences are available only to men with big equipment. Your girl can already start fantasizing about the huge you come and please her like never before. Find what you need here: http://www.posadroft.com/gal/ms/
Unlike other products, this one gives you permanent gains in size - and loads of pleasure!
It is a long lane that has no turning After dinner rest a while, after supper walk a mile Another day, another dollar Listen to advice and accept instruction, and in the end you will be wise An apple a day keeps the doctor at bay Stir With a Knife, Stir Up Strife
^ permalink raw reply
* Be delighted with Act while others wait! Increase your confidence to enormous levels!
From: Mildred @ 2006-08-19 10:32 UTC (permalink / raw)
To: glenda
Enjoy the newest
Act while others wait! Increase your confidence to enormous levels! You are about to gain inches in months or even less - get ready to have more fun!
Just think how you would enjoy the new-found confidence and the feeling of power. You can mark inches on your ruler, expecting your intimate tool to gain a lot in size. Find what you need: http://www.posadroft.com/gal/ms/
You don't need to spend huge money on luxury items - it all will be worthless without decent physical equipment.
A fool finds no pleasure in understanding but delights in airing his own opinions. A hairy man is a happy man, a hairy wife is a witch. Give a clown a finger and he will take your hand As you shall make your bed, so shall you..........mess it up.
^ permalink raw reply
* Re: recur status on linux-2.6
From: Fredrik Kuivinen @ 2006-08-19 10:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608131550290.10541@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, Aug 13, 2006 at 03:54:19PM +0200, Johannes Schindelin wrote:
> Hi,
>
> I tested git-merge-recur vs. git-merge-recursive on the linux-2.6
> repository last night. It contains 2298 two-head merges. _All_ of them
> come out identically with -recur as compared to -recursive (looking at
> the resulting index only).
After the latest updates to git-merge-recur it passes all the tests I
have too.
> That was the good news. The bad news is: it _seems_, that -recur is only
> about 6x faster than -recursive, not 10x, and this number becomes smaller,
> the longer the merge takes. So I see a startup effect here, probably.
That is a quite nice improvement anyway :)
- Fredrik
^ 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