* Re: [PATCH] Allow an alias to start with "-p"
From: Johannes Schindelin @ 2006-07-25 6:18 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060725050312.GA5618@coredump.intra.peff.net>
Hi,
On Tue, 25 Jul 2006, Jeff King wrote:
> On Mon, Jul 24, 2006 at 02:10:45PM +0200, Johannes Schindelin wrote:
>
> > @@ -264,6 +289,7 @@ int main(int argc, const char **argv, ch
> > if (!strncmp(cmd, "git-", 4)) {
> > cmd += 4;
> > argv[0] = cmd;
> > + handle_alias(&argc, &argv);
> > handle_internal_command(argc, argv, envp);
> > die("cannot handle %s internally", cmd);
> > }
My fault. This was a left-over from my original alias patch. (I did a
merge, and just used "git-diff next" instead of "git-diff --merge next".
<Clickety-click/> Nope, that would not have worked either.
> Patch is below (wow, that +++ is kind of ugly!).
Same here.
> git: choose internal commands over aliases for git-*
>
> This is especially important because some commands (like init-db) don't
> require a working GIT_DIR, and alias expansion tries to look at it. It
> also matches the behavior of "git cmd".
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> @@ -289,8 +289,8 @@ int main(int argc, const char **argv, ch
> if (!strncmp(cmd, "git-", 4)) {
> cmd += 4;
> argv[0] = cmd;
> - handle_alias(&argc, &argv);
> handle_internal_command(argc, argv, envp);
> + handle_alias(&argc, &argv);
> die("cannot handle %s internally", cmd);
> }
Alternatively, you can just delete it. IIRC we decided that aliases with
"git-" commands do not make sense.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow an alias to start with "-p"
From: Johannes Schindelin @ 2006-07-25 6:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virlmfrl4.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 24 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, something like
> >
> > [alias]
> > pd = -p diff
> >
> > works as expected.
> >
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> This seems to break t5400 among other things (git-clone
> complains that it is not invoked in a git repository).
See Peff's mail for a fix (hopefully: I do not see why git-clone should
be affected, as it is a script, not a hard link to the git wrapper). The
funny thing: t5400 does not break here.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Substitute xmalloc()+memset(0) with xcalloc().
From: Peter Eriksen @ 2006-07-25 7:30 UTC (permalink / raw)
To: git
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
builtin-add.c | 3 +--
builtin-rm.c | 3 +--
combine-diff.c | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 2d25698..3a73a17 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -21,8 +21,7 @@ static void prune_directory(struct dir_s
for (specs = 0; pathspec[specs]; specs++)
/* nothing */;
- seen = xmalloc(specs);
- memset(seen, 0, specs);
+ seen = xcalloc(specs, 1);
src = dst = dir->entries;
i = dir->nr;
diff --git a/builtin-rm.c b/builtin-rm.c
index 5deb811..bb810ba 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -90,8 +90,7 @@ int cmd_rm(int argc, const char **argv,
seen = NULL;
for (i = 0; pathspec[i] ; i++)
/* nothing */;
- seen = xmalloc(i);
- memset(seen, 0, i);
+ seen = xcalloc(i, 1);
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
diff --git a/combine-diff.c b/combine-diff.c
index 1bc1484..919112b 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -639,8 +639,7 @@ static int show_patch_diff(struct combin
/* deleted file */
result_size = 0;
elem->mode = 0;
- result = xmalloc(1);
- result[0] = 0;
+ result = xcalloc(1, 1);
}
if (0 <= fd)
close(fd);
--
1.4.2.rc1.ge7a0
^ permalink raw reply related
* Better Life, working fit
From: Herman Hutton @ 2006-07-25 10:14 UTC (permalink / raw)
To: git-commits-head-owner
Your cre dit doesn't matter to us! If you OWN real est ate
and want IMMEDIATEV cash to spend ANY way you like, or simply wish
to LOWER your monthly paym ents by a third or more, here are the dea ls
we have TODAY (hurry, these ofers will expre TONIGHT):
$488,000.00 at a 3.67,% fixed-rateJ
$372,000.00 at a 3.90,% variable-rateP
$492,000.00 at a 3.21,% interest-only2
$248,000.00 at a 3.36,% fixed-rate0
$198,000.00 at a 3.55,% variable-rateL
Hurry, when these deals are gone, they are gone Simply fill out this one-min ute form...
Don't worry about approval, your cre dit will not disqualify you!
http://V2NBH159.fortessed.com
"Look at that, Mr. Schuhart," he said, livening up. "Father must have
many of the tales had it. It lay where it had fallen. Maybe it had fallen
promises--I've had enough, you've led me by the nose long enough. All my
to do, don't suddenly be afraid of the dirt. If I tell you to, drop your
explanation of what was going on. Redrick listened for a minute or two and
was about to start when he stopped suddenly.
stalactites that looked like fat candles hanging from the jagged edges of
Every step raised a cloud of white dust, and the dust settled on his
have happened, he would have gotten blisters on his feet--and that would
Buzzard. If you only knew, Buzzard, that I took your advice this time. "This
The mud slurped underfoot. It was a dead swamp--no bugs, no frogs, even the
^ permalink raw reply
* [PATCH] cvsserver: suppress warnings
From: Johannes Schindelin @ 2006-07-25 10:48 UTC (permalink / raw)
To: git, junkio, Martin Langhoff
This patch defines $state->{prependdir} as the empty string, so that
quite a few warnings are avoided.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I still get this warning:
closing dbh with active statement handles
git-cvsserver.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 9c9f21b..981b6ba 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -81,7 +81,7 @@ ########################################
# $state holds all the bits of information the clients sends us that could
# potentially be useful when it comes to actually _doing_ something.
-my $state = {};
+my $state = { prependdir => '' };
$log->info("--------------- STARTING -----------------");
my $TEMP_DIR = tempdir( CLEANUP => 1 );
--
1.4.2.rc1.gc123
^ permalink raw reply related
* Re: [PATCH] cvsserver: suppress warnings
From: Martin Langhoff (CatalystIT) @ 2006-07-25 11:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251247040.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> This patch defines $state->{prependdir} as the empty string, so that
> quite a few warnings are avoided.
Ack.
> I still get this warning:
>
> closing dbh with active statement handles
Ack to that too. Perhaps an END block would help? A quick check of man
DBI tells me that $dbh->CachedKids will be a hashref where the values
are refs to the cached statement handles.
IMHO it's a DBI bug -- statement handles only referenced by
$dbh->CachedKids should cleanup silently. prepare_cached() is a
convenience method so that you _don't_ have to keep track of the handles
manually. Forcing a manual cleanup throws a good part of the convenience
out.
cheers,
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] cvsserver: suppress warnings
From: Johannes Schindelin @ 2006-07-25 11:11 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: git, junkio
In-Reply-To: <44C5FB3E.9020301@catalyst.net.nz>
Hi,
On Tue, 25 Jul 2006, Martin Langhoff (CatalystIT) wrote:
> Johannes Schindelin wrote:
>
> > I still get this warning:
> >
> > closing dbh with active statement handles
>
> Ack to that too. Perhaps an END block would help?
Since my BASIC days on a VC-20 (no, not the airplane), I hardly used an
END statement ;-) Well, maybe in that Pascal course, but not in Perl,
anyway. So, I do not understand...
> A quick check of man DBI tells me that $dbh->CachedKids will be a
> hashref where the values are refs to the cached statement handles.
>
> IMHO it's a DBI bug -- statement handles only referenced by $dbh->CachedKids
> should cleanup silently. prepare_cached() is a convenience method so that you
> _don't_ have to keep track of the handles manually. Forcing a manual cleanup
> throws a good part of the convenience out.
I agree fully.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsserver: suppress warnings
From: Martin Langhoff @ 2006-07-25 11:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251308380.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 7/25/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Ack to that too. Perhaps an END block would help?
>
> Since my BASIC days on a VC-20 (no, not the airplane), I hardly used an
> END statement ;-) Well, maybe in that Pascal course, but not in Perl,
> anyway. So, I do not understand...
Oh, it's a code block you can declare that gets called when the
program is exiting. More info at
http://search.cpan.org/dist/perl/pod/perlmod.pod#BEGIN%2C_CHECK%2C_INIT_and_END____
No relation to BASIC's END ;-)
martin
^ permalink raw reply
* Re: [PATCH] cvsserver: suppress warnings
From: Johannes Schindelin @ 2006-07-25 11:56 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <46a038f90607250450l643f97e4sbece300fa5b2d509@mail.gmail.com>
Hi,
On Tue, 25 Jul 2006, Martin Langhoff wrote:
> On 7/25/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > Ack to that too. Perhaps an END block would help?
> >
> > Since my BASIC days on a VC-20 (no, not the airplane), I hardly used an
> > END statement ;-) Well, maybe in that Pascal course, but not in Perl,
> > anyway. So, I do not understand...
>
> Oh, it's a code block you can declare that gets called when the
> program is exiting. More info at
> http://search.cpan.org/dist/perl/pod/perlmod.pod#BEGIN%2C_CHECK%2C_INIT_and_END____
Ah! Something like "atexit()".
> No relation to BASIC's END ;-)
;-)
BTW I will send out a proper patch for that warning shortly.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] cvsserver: avoid warning about active db handles
From: Johannes Schindelin @ 2006-07-25 11:57 UTC (permalink / raw)
To: git, Martin Langhoff (CatalystIT), junkio
Turns out that DBD::SQLite does not favour preparing statements which are
never executed. So, turn all 4 statements, which were prepared _always_,
into methods, like the other 12 prepared statements.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Now, the only warning left is the gzip one...
git-cvsserver.perl | 70 ++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 56 insertions(+), 14 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 981b6ba..b2837ad 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -2131,12 +2131,6 @@ sub update
# first lets get the commit list
$ENV{GIT_DIR} = $self->{git_path};
- # prepare database queries
- my $db_insert_rev = $self->{dbh}->prepare_cached("INSERT INTO revision (name, revision, filehash, commithash, modified, author, mode) VALUES (?,?,?,?,?,?,?)",{},1);
- my $db_insert_mergelog = $self->{dbh}->prepare_cached("INSERT INTO commitmsgs (key, value) VALUES (?,?)",{},1);
- my $db_delete_head = $self->{dbh}->prepare_cached("DELETE FROM head",{},1);
- my $db_insert_head = $self->{dbh}->prepare_cached("INSERT INTO head (name, revision, filehash, commithash, modified, author, mode) VALUES (?,?,?,?,?,?,?)",{},1);
-
my $commitinfo = `git-cat-file commit $self->{module} 2>&1`;
unless ( $commitinfo =~ /tree\s+[a-zA-Z0-9]{40}/ )
{
@@ -2325,7 +2319,7 @@ sub update
author => $commit->{author},
mode => $git_perms,
};
- $db_insert_rev->execute($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
+ $self->insert_rev($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
}
elsif ( $3 eq "M" )
{
@@ -2339,7 +2333,7 @@ sub update
author => $commit->{author},
mode => $git_perms,
};
- $db_insert_rev->execute($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
+ $self->insert_rev($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
}
elsif ( $3 eq "A" )
{
@@ -2353,7 +2347,7 @@ sub update
author => $commit->{author},
mode => $git_perms,
};
- $db_insert_rev->execute($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
+ $self->insert_rev($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
}
else
{
@@ -2410,7 +2404,7 @@ sub update
};
- $db_insert_rev->execute($git_filename, $newrevision, $git_hash, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
+ $self->insert_rev($git_filename, $newrevision, $git_hash, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
}
}
close FILELIST;
@@ -2426,7 +2420,7 @@ sub update
$head->{$file}{modified} = $commit->{date};
$head->{$file}{author} = $commit->{author};
- $db_insert_rev->execute($file, $head->{$file}{revision}, $head->{$file}{filehash}, $commit->{hash}, $commit->{date}, $commit->{author}, $head->{$file}{mode});
+ $self->insert_rev($file, $head->{$file}{revision}, $head->{$file}{filehash}, $commit->{hash}, $commit->{date}, $commit->{author}, $head->{$file}{mode});
}
}
# END : "Detect deleted files"
@@ -2435,7 +2429,7 @@ sub update
if (exists $commit->{mergemsg})
{
- $db_insert_mergelog->execute($commit->{hash}, $commit->{mergemsg});
+ $self->insert_mergelog($commit->{hash}, $commit->{mergemsg});
}
$lastpicked = $commit->{hash};
@@ -2443,10 +2437,10 @@ sub update
$self->_set_prop("last_commit", $commit->{hash});
}
- $db_delete_head->execute();
+ $self->delete_head();
foreach my $file ( keys %$head )
{
- $db_insert_head->execute(
+ $self->insert_head(
$file,
$head->{$file}{revision},
$head->{$file}{filehash},
@@ -2464,6 +2458,54 @@ sub update
$self->{dbh}->commit() or die "Failed to commit changes to SQLite";
}
+sub insert_rev
+{
+ my $self = shift;
+ my $name = shift;
+ my $revision = shift;
+ my $filehash = shift;
+ my $commithash = shift;
+ my $modified = shift;
+ my $author = shift;
+ my $mode = shift;
+
+ my $insert_rev = $self->{dbh}->prepare_cached("INSERT INTO revision (name, revision, filehash, commithash, modified, author, mode) VALUES (?,?,?,?,?,?,?)",{},1);
+ $insert_rev->execute($name, $revision, $filehash, $commithash, $modified, $author, $mode);
+}
+
+sub insert_mergelog
+{
+ my $self = shift;
+ my $key = shift;
+ my $value = shift;
+
+ my $insert_mergelog = $self->{dbh}->prepare_cached("INSERT INTO commitmsgs (key, value) VALUES (?,?)",{},1);
+ $insert_mergelog->execute($key, $value);
+}
+
+sub delete_head
+{
+ my $self = shift;
+
+ my $delete_head = $self->{dbh}->prepare_cached("DELETE FROM head",{},1);
+ $delete_head->execute();
+}
+
+sub insert_head
+{
+ my $self = shift;
+ my $name = shift;
+ my $revision = shift;
+ my $filehash = shift;
+ my $commithash = shift;
+ my $modified = shift;
+ my $author = shift;
+ my $mode = shift;
+
+ my $insert_head = $self->{dbh}->prepare_cached("INSERT INTO head (name, revision, filehash, commithash, modified, author, mode) VALUES (?,?,?,?,?,?,?)",{},1);
+ $insert_head->execute($name, $revision, $filehash, $commithash, $modified, $author, $mode);
+}
+
sub _headrev
{
my $self = shift;
--
1.4.2.rc1.gd3c5-dirty
^ permalink raw reply related
* git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Mike Galbraith @ 2006-07-25 12:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0607251247040.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Greetings,
Having finally acquired DSL (only 400kbps, but at least I'm in the
twentieth century [not typo]), I decided to finally give git a try. I
installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
get far before git saved me the trouble of truly testing my resolve :)
-Mike
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
error: git-clone-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
^ permalink raw reply
* Re: [PATCH] cvsserver: avoid warning about active db handles
From: Martin Langhoff (CatalystIT) @ 2006-07-25 12:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251356430.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Turns out that DBD::SQLite does not favour preparing statements which are
> never executed. So, turn all 4 statements, which were prepared _always_,
> into methods, like the other 12 prepared statements.
Can you give me a reference for that "does not favour preparing
statements"? I have some vague recollection of timing
prepared/unprepared inserts and getting a huge difference in
performance. Looking at the source of SQLite.pm doesn't clarify much --
prepare_cached is actually implemented by DBI, the driver doesn't need
to implement it. Anyway, I guess it has to do with the cost of preparing
it in the lower level driver anyway.
> Now, the only warning left is the gzip one...
That's harder. I wonder whether using libgit's XS module we can now get
libgit to give us a gzipped file directly. I guess it only has
performance savings for unpacked repos.
cheers,
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Mike Galbraith @ 2006-07-25 12:18 UTC (permalink / raw)
To: git
In-Reply-To: <1153829608.2258.32.camel@Homer.simpson.net>
On Tue, 2006-07-25 at 14:13 +0200, Mike Galbraith wrote:
> Greetings,
>
> Having finally acquired DSL (only 400kbps, but at least I'm in the
> twentieth century [not typo]), I decided to finally give git a try. I
> installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
> get far before git saved me the trouble of truly testing my resolve :)
>
> -Mike
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
Oops, missed a line.
fatal: packfile '/usr/local/src/tmp/linux-2.6/.git/objects/pack/tmp-nE9k3G' SHA1 mismatch
> error: git-clone-pack: unable to read from git-index-pack
> error: git-index-pack died with error code 128
> clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
^ permalink raw reply
* Re: [PATCH] cvsserver: avoid warning about active db handles
From: Johannes Schindelin @ 2006-07-25 14:53 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: git, junkio
In-Reply-To: <44C6099A.5010205@catalyst.net.nz>
Hi,
[sorry for the delay... darn meetings]
On Wed, 26 Jul 2006, Martin Langhoff (CatalystIT) wrote:
> Johannes Schindelin wrote:
>
> > Turns out that DBD::SQLite does not favour preparing statements which
> > are never executed. So, turn all 4 statements, which were prepared
> > _always_, into methods, like the other 12 prepared statements.
>
> Can you give me a reference for that "does not favour preparing
> statements"?
The relevant bug entry is
http://rt.cpan.org/Public/Bug/Display.html?id=17603
> I have some vague recollection of timing prepared/unprepared inserts and
> getting a huge difference in performance.
Yes, preparing before executing is a wonderful thing. But you need to
execute the prepared statements; otherwise it is a waste of resources
(plus, it does not finalize with DBD::SQLite).
> Looking at the source of SQLite.pm doesn't clarify much --
> prepare_cached is actually implemented by DBI, the driver doesn't need
> to implement it.
Yes. The culprit is in prepare().
> > Now, the only warning left is the gzip one...
>
> That's harder. I wonder whether using libgit's XS module we can now get
> libgit to give us a gzipped file directly. I guess it only has
> performance savings for unpacked repos.
I still have the problem on at least two of my boxes that Git.xs does not
load. The next thing after looking into the gzip thing is to rewrite
git-mv in C.
Ciao,
Dscho
^ permalink raw reply
* Re: git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Johannes Schindelin @ 2006-07-25 14:57 UTC (permalink / raw)
To: Mike Galbraith; +Cc: git
In-Reply-To: <1153829908.2258.34.camel@Homer.simpson.net>
Hi,
On Tue, 25 Jul 2006, Mike Galbraith wrote:
> On Tue, 2006-07-25 at 14:13 +0200, Mike Galbraith wrote:
> > Greetings,
> >
> > Having finally acquired DSL (only 400kbps, but at least I'm in the
> > twentieth century [not typo]), I decided to finally give git a try. I
> > installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
> > get far before git saved me the trouble of truly testing my resolve :)
> >
> > -Mike
> >
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
>
> Oops, missed a line.
>
> fatal: packfile '/usr/local/src/tmp/linux-2.6/.git/objects/pack/tmp-nE9k3G' SHA1 mismatch
>
> > error: git-clone-pack: unable to read from git-index-pack
> > error: git-index-pack died with error code 128
> > clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
Was this after about 10 minutes? I had the impression that this was fixed
with the 1.4.1.1 version _on the server side_. See
http://www.kernel.org/git/gitweb.cgi?p=git/git.git;a=commit;h=a0764cb838c2f1885fb58ca794c21523fb05c825
for details. So, please be patient until kernel.org's server is updated.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsserver: avoid warning about active db handles
From: Petr Baudis @ 2006-07-25 15:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251649190.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Tue, Jul 25, 2006 at 04:53:16PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > That's harder. I wonder whether using libgit's XS module we can now get
> > libgit to give us a gzipped file directly. I guess it only has
> > performance savings for unpacked repos.
the object in the database is compressed together with the header, so
we have to recompress it anyway.
> I still have the problem on at least two of my boxes that Git.xs does not
> load.
What is the problem? I must have overlooked it, sorry. :-(
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Git.xs problem, was Re: [PATCH] cvsserver: avoid warning about active db handles
From: Johannes Schindelin @ 2006-07-25 16:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <20060725155259.GU13776@pasky.or.cz>
Hi,
On Tue, 25 Jul 2006, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Tue, Jul 25, 2006 at 04:53:16PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
>
> > I still have the problem on at least two of my boxes that Git.xs does not
> > load.
>
> What is the problem? I must have overlooked it, sorry. :-(
Still that darn private_Error.pm thing requiring Scalar::Util, IIRC.
Ciao,
Dscho
^ permalink raw reply
* [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Johannes Schindelin @ 2006-07-25 17:30 UTC (permalink / raw)
To: git, junkio
With this, you can say
git --bare repack -a -d
inside a bare repository, and it will actually work. While at
documenting these options, also document the --paginate option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is on top of my "allow wrapper options in aliases" patch.
I hope I did not fsck up the asciidoc formatting; ATM I cannot
test that.
If you agree this is a good approach, should I also move the
--version and --exec-path options into handle_options()?
If you do, I will also make this more user-friendly, i.e.
it should not crash when saying "git --bare".
Documentation/git.txt | 12 +++++++++++-
git.c | 9 +++++++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ce30581..b5da5f9 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -8,7 +8,8 @@ git - the stupid content tracker
SYNOPSIS
--------
-'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ARGS]
+'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate]
+ [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
DESCRIPTION
-----------
@@ -41,6 +42,15 @@ OPTIONS
environment variable. If no path is given 'git' will print
the current setting and then exit.
+-p|--paginate::
+ Pipe all output into 'less' (or if set, $PAGER).
+
+--git-path=<path>::
+ Set the path to the repository. This can also be controlled by
+ setting the GIT_DIR environment variable.
+
+--bare::
+ Same as --git-path=`pwd`.
FURTHER DOCUMENTATION
---------------------
diff --git a/git.c b/git.c
index 8d7c644..e048f54 100644
--- a/git.c
+++ b/git.c
@@ -46,6 +46,15 @@ static int handle_options(const char***
if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
setup_pager();
+ } else if (!strcmp(cmd, "--git-dir") && *argc > 1) {
+ setenv("GIT_DIR", (*argv)[1], 1);
+ (*argv)++;
+ (*argc)--;
+ } else if (!strncmp(cmd, "--git-dir=", 10)) {
+ setenv("GIT_DIR", cmd + 10, 1);
+ } else if (!strcmp(cmd, "--bare")) {
+ static char git_dir[1024];
+ setenv("GIT_DIR", getcwd(git_dir, 1024), 1);
} else
die ("Unknown option: %s", cmd);
--
1.4.2.rc1.gf725-dirty
^ permalink raw reply related
* Re: [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Linus Torvalds @ 2006-07-25 17:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251926190.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 25 Jul 2006, Johannes Schindelin wrote:
>
> SYNOPSIS
> --------
> -'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ARGS]
> +'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate]
> + [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
Here you have "--git-dir"
> @@ -41,6 +42,15 @@ OPTIONS
> environment variable. If no path is given 'git' will print
> the current setting and then exit.
>
> +-p|--paginate::
> + Pipe all output into 'less' (or if set, $PAGER).
> +
> +--git-path=<path>::
> + Set the path to the repository. This can also be controlled by
> + setting the GIT_DIR environment variable.
But here you have "--git-path".
> + } else if (!strcmp(cmd, "--git-dir") && *argc > 1) {
> + setenv("GIT_DIR", (*argv)[1], 1);
> + (*argv)++;
> + (*argc)--;
> + } else if (!strncmp(cmd, "--git-dir=", 10)) {
> + setenv("GIT_DIR", cmd + 10, 1);
And here you have "--git-dir" again.
Since "--git-dir" makes more sense than "--git-path", I'd suggest just
fixing the OPTIONS section ;)
Linus
^ permalink raw reply
* Re: [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Johannes Schindelin @ 2006-07-25 17:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.64.0607251042120.29649@g5.osdl.org>
Hi,
On Tue, 25 Jul 2006, Linus Torvalds wrote:
> Since "--git-dir" makes more sense than "--git-path", I'd suggest just
> fixing the OPTIONS section ;)
Will do. Thanks.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git wrapper: add --git-path=<path> and --bare options
From: Johannes Schindelin @ 2006-07-25 18:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251952000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
With this, you can say
git --bare repack -a -d
inside a bare repository, and it will actually work. While at it,
also move the --version, --help and --exec-path options to the
handle_options() function.
While at documenting the new options, also document the --paginate
option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
The change in builtin-help.c is not only clean, but is also
necessary for t0000 on cygwin.
I have to run off now, but will answer your comments in
about three hours.
Documentation/git.txt | 12 ++++++
builtin-help.c | 2 +
git.c | 93 +++++++++++++++++++++++++------------------------
3 files changed, 60 insertions(+), 47 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ce30581..29aebe9 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -8,7 +8,8 @@ git - the stupid content tracker
SYNOPSIS
--------
-'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ARGS]
+'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate]
+ [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
DESCRIPTION
-----------
@@ -41,6 +42,15 @@ OPTIONS
environment variable. If no path is given 'git' will print
the current setting and then exit.
+-p|--paginate::
+ Pipe all output into 'less' (or if set, $PAGER).
+
+--git-dir=<path>::
+ Set the path to the repository. This can also be controlled by
+ setting the GIT_DIR environment variable.
+
+--bare::
+ Same as --git-path=`pwd`.
FURTHER DOCUMENTATION
---------------------
diff --git a/builtin-help.c b/builtin-help.c
index 335fe5f..bc1b4da 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -229,7 +229,7 @@ int cmd_version(int argc, const char **a
int cmd_help(int argc, const char **argv, char **envp)
{
- const char *help_cmd = argv[1];
+ const char *help_cmd = argc > 1 ? argv[1] : NULL;
if (!help_cmd)
cmd_usage(0, git_exec_path(), NULL);
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a"))
diff --git a/git.c b/git.c
index 8d7c644..e4b2174 100644
--- a/git.c
+++ b/git.c
@@ -44,10 +44,44 @@ static int handle_options(const char***
if (cmd[0] != '-')
break;
- if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
+ /*
+ * For legacy reasons, the "version" and "help"
+ * commands can be written with "--" prepended
+ * to make them look like flags.
+ */
+ if (!strcmp(cmd, "--help") || !strcmp(cmd, "--version"))
+ break;
+
+ /*
+ * Check remaining flags (which by now must be
+ * "--exec-path", but maybe we will accept
+ * other arguments some day)
+ */
+ if (!strncmp(cmd, "--exec-path", 11)) {
+ cmd += 11;
+ if (*cmd == '=')
+ git_set_exec_path(cmd + 1);
+ else {
+ puts(git_exec_path());
+ exit(0);
+ }
+ } else if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
setup_pager();
- } else
- die ("Unknown option: %s", cmd);
+ } else if (!strcmp(cmd, "--git-dir")) {
+ if (*argc < 1)
+ return -1;
+ setenv("GIT_DIR", (*argv)[1], 1);
+ (*argv)++;
+ (*argc)--;
+ } else if (!strncmp(cmd, "--git-dir=", 10)) {
+ setenv("GIT_DIR", cmd + 10, 1);
+ } else if (!strcmp(cmd, "--bare")) {
+ static char git_dir[1024];
+ setenv("GIT_DIR", getcwd(git_dir, 1024), 1);
+ } else {
+ fprintf(stderr, "Unknown option: %s\n", cmd);
+ cmd_usage(0, NULL, NULL);
+ }
(*argv)++;
(*argc)--;
@@ -294,50 +328,19 @@ int main(int argc, const char **argv, ch
die("cannot handle %s internally", cmd);
}
- /* Default command: "help" */
- cmd = "help";
-
/* Look for flags.. */
- while (argc > 1) {
- argv++;
- argc--;
-
- handle_options(&argv, &argc);
-
- cmd = *argv;
-
- if (strncmp(cmd, "--", 2))
- break;
-
- cmd += 2;
-
- /*
- * For legacy reasons, the "version" and "help"
- * commands can be written with "--" prepended
- * to make them look like flags.
- */
- if (!strcmp(cmd, "help"))
- break;
- if (!strcmp(cmd, "version"))
- break;
-
- /*
- * Check remaining flags (which by now must be
- * "--exec-path", but maybe we will accept
- * other arguments some day)
- */
- if (!strncmp(cmd, "exec-path", 9)) {
- cmd += 9;
- if (*cmd == '=') {
- git_set_exec_path(cmd + 1);
- continue;
- }
- puts(git_exec_path());
- exit(0);
- }
- cmd_usage(0, NULL, NULL);
+ argv++;
+ argc--;
+ handle_options(&argv, &argc);
+ if (argc > 0) {
+ if (!strncmp(argv[0], "--", 2))
+ argv[0] += 2;
+ } else {
+ /* Default command: "help" */
+ argv[0] = "help";
+ argc = 1;
}
- argv[0] = cmd;
+ cmd = argv[0];
/*
* We search for git commands in the following order:
--
1.4.2.rc1.g8b0c5
^ permalink raw reply related
* Handling very large numbers of symbolic references?
From: Nix @ 2006-07-25 19:29 UTC (permalink / raw)
To: git
I'm about to start writing my first git porcelain (to try to convert my
workplace from the world's oldest and cruftiest version control system
to something not based on the bastard offspring of SCCS and VMS's CMS,
with less power than either) and have run into a problem that I'm not
sure how to solve.
The biggest problem with git for totally naive users is that they get
scared by the sha1 IDs used as version numbers (assuming the index is
porcelained away: but that would confuse them, not scare them). They're
not pronounceable, not memorable, and so on. So the porcelain I'm
whipping up conceals them in large part by using instead bug IDs, as the
workflow of the place I'm doing this for is driven entirely by Bugzilla
bug numbers.
I'm taking a leaf from the `git for the ignorant' document and arranging
that every fix that fixes some Bugzilla bug is on a branch named after
that bug, e.g. #2243, #10155, whatever. (I'm going to have to go further
than that and track dependency relationships between bugs, i.e. `if you
merge bug #1404's branch, you must merge #1306's and #1505's as well'. I
could do that by adding a new bug-dependency object, respected by a
wrapper around git-merge, but I'm not sure how kosher it is to add new
types of objects only used by porcelain. Hell, I'm not even sure if it's
possible yet.)
However, this causes a potential problem. There are tens of thousands of
these bugs, and the .git/refs/heads directory gets *enormous* and thus
the system gets terribly terribly slow (crappy old Solaris filesystem
syndrome).
It seems to me there are two ways to fix this:
- restructure .git/refs/* in a similar way to .git/objects, i.e. as a
one- or two-level tree.
- the vast majority of these bugs are closed. They still need to be got
at now and again for branch merges, but they could be got out of
.refs/heads at delete_branch time, and pushed into a tree consisting
entirely of deleted branches, which would in turn be pointed at from
some new place under .refs; perhaps .refs/heads/heavy (by analogy to
non-lightweight tags). The problem here is that whenever we delete
a tag, we'll leak that tree (at least we will if it's in a pack), and
that leakage really could add up in the end.
(Deleting branches corresponding to closed bugs is good for other
reasons: e.g., it cleans up gitweb output. But certain tools *will*
need to get at those closed bug branches: I'm inclined to say that
all of them will sooner or later, because the users aren't going to
tolerate being told that they can't do anything to a closed
bug. Except for adding code to it: we can reasonably declare the
addition of commits to those branches over. Of course once we have
the sha1 id, it's all academic, really.)
I'm not sure which way is preferable. Suggestions? Is the entire idea
lunatic?
And, in case this hasn't been said enough: thank you for git, it's the
nicest version control system I've used in years, and the way it's
structured encourages everyone to play :)
--
`We're sysadmins. We deal with the inconceivable so often I can clearly
see the need to define levels of inconceivability.' --- Rik Steenwinkel
^ permalink raw reply
* Re: git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Ryan Anderson @ 2006-07-25 20:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mike Galbraith, git
In-Reply-To: <Pine.LNX.4.63.0607251655360.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jul 25, 2006 at 04:57:39PM +0200, Johannes Schindelin wrote:
> On Tue, 25 Jul 2006, Mike Galbraith wrote:
>
> > On Tue, 2006-07-25 at 14:13 +0200, Mike Galbraith wrote:
> > > Greetings,
> > >
> > > Having finally acquired DSL (only 400kbps, but at least I'm in the
> > > twentieth century [not typo]), I decided to finally give git a try. I
> > > installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
> > > get far before git saved me the trouble of truly testing my resolve :)
> > >
> > > -Mike
> > >
> > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> >
> > Oops, missed a line.
> >
> > fatal: packfile '/usr/local/src/tmp/linux-2.6/.git/objects/pack/tmp-nE9k3G' SHA1 mismatch
> >
> > > error: git-clone-pack: unable to read from git-index-pack
> > > error: git-index-pack died with error code 128
> > > clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
>
> Was this after about 10 minutes? I had the impression that this was fixed
> with the 1.4.1.1 version _on the server side_. See
>
> http://www.kernel.org/git/gitweb.cgi?p=git/git.git;a=commit;h=a0764cb838c2f1885fb58ca794c21523fb05c825
>
> for details. So, please be patient until kernel.org's server is updated.
Or do your initial clone as:
git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
cd linux-2.6 && sed -i -e 's/rsync/git/g' .git/remotes/origin
(The preferred thing is for the method you used to work, but the above
will avoid the bug for the moment.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Allow an alias to start with "-p"
From: Junio C Hamano @ 2006-07-25 20:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jeff King
In-Reply-To: <Pine.LNX.4.63.0607250813450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Patch is below (wow, that +++ is kind of ugly!).
>
> Same here.
Same here ;-).
> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
>> @@ -289,8 +289,8 @@ int main(int argc, const char **argv, ch
>> if (!strncmp(cmd, "git-", 4)) {
>> cmd += 4;
>> argv[0] = cmd;
>> - handle_alias(&argc, &argv);
>> handle_internal_command(argc, argv, envp);
>> + handle_alias(&argc, &argv);
>> die("cannot handle %s internally", cmd);
>> }
>
> Alternatively, you can just delete it. IIRC we decided that aliases with
> "git-" commands do not make sense.
I think that is reasonable and simpler.
^ permalink raw reply
* Re: [PATCH] git wrapper: add --git-path=<path> and --bare options
From: Junio C Hamano @ 2006-07-25 21:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607252022370.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this, you can say
>
> git --bare repack -a -d
>
> inside a bare repository, and it will actually work. While at it,
> also move the --version, --help and --exec-path options to the
> handle_options() function.
Thanks. Took a liberty cleaning up a few stuff, but will have
both alias-p and this patch in "next" shortly.
^ 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