* [PATCH 1/2] cvsimport: use git-update-index --index-info
From: Jeff King @ 2006-05-23 7:27 UTC (permalink / raw)
To: git; +Cc: martin, junkio
In-Reply-To: <20060523070007.GC6180@coredump.intra.peff.net>
This should reduce the number of git-update-index forks required per
commit. We now do adds/removes in one call, and we are no longer forced to
deal with argv limitations.
---
This is a repost using -z/NUL instead of line feeds.
d82d215430ae5e79210f73a31f5f8a053f36c27f
git-cvsimport.perl | 36 +++++++++++++-----------------------
1 files changed, 13 insertions(+), 23 deletions(-)
d82d215430ae5e79210f73a31f5f8a053f36c27f
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index d257e66..a65bea6 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -565,29 +565,19 @@ my($patchset,$date,$author_name,$author_
my(@old,@new,@skipped);
sub commit {
my $pid;
- while(@old) {
- my @o2;
- if(@old > 55) {
- @o2 = splice(@old,0,50);
- } else {
- @o2 = @old;
- @old = ();
- }
- system("git-update-index","--force-remove","--",@o2);
- die "Cannot remove files: $?\n" if $?;
- }
- while(@new) {
- my @n2;
- if(@new > 12) {
- @n2 = splice(@new,0,10);
- } else {
- @n2 = @new;
- @new = ();
- }
- system("git-update-index","--add",
- (map { ('--cacheinfo', @$_) } @n2));
- die "Cannot add files: $?\n" if $?;
- }
+
+ open(my $fh, '|-', qw(git-update-index -z --index-info))
+ or die "unable to open git-update-index: $!";
+ print $fh
+ (map { "0 0000000000000000000000000000000000000000\t$_\0" }
+ @old),
+ (map { '100' . sprintf('%o', $_->[0]) . " $_->[1]\t$_->[2]\0" }
+ @new)
+ or die "unable to write to git-update-index: $!";
+ close $fh
+ or die "unable to write to git-update-index: $!";
+ $? and die "git-update-index reported error: $?";
+ @old = @new = ();
$pid = open(C,"-|");
die "Cannot fork: $!" unless defined $pid;
--
1.3.3.g3408
^ permalink raw reply related
* [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-23 7:27 UTC (permalink / raw)
To: git; +Cc: martin, junkio
In-Reply-To: <1148369266352-git-send-email-1>
This change attempts to clean up the commit function to make it a bit
easier to read (or at least the first half of it). It also improves
robustness and performance. Specifically:
- report get_headref errors on opening ref unless the error is ENOENT
- use regex to check for sha1 instead of length
- use lexically scoped filehandles which get cleaned up automagically
- check for error on both 'print' and 'close' (since output is buffered)
- avoid "fork, do some perl, then exec" in commit(). It's not necessary,
and we probably end up COW'ing parts of the perl process. Plus the code
is much smaller because we can use open2()
- avoid calling strftime over and over (mainly a readability cleanup)
---
This is a repost with some minor fixups from Junio (and based off of the
fixed 1/2 patch).
3408c8d8364f816a7c4a34a03045f466bf028540
git-cvsimport.perl | 150 ++++++++++++++++++++++------------------------------
1 files changed, 64 insertions(+), 86 deletions(-)
3408c8d8364f816a7c4a34a03045f466bf028540
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index a65bea6..219f6dc 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -23,7 +23,7 @@ use File::Basename qw(basename dirname);
use Time::Local;
use IO::Socket;
use IO::Pipe;
-use POSIX qw(strftime dup2);
+use POSIX qw(strftime dup2 :errno_h);
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
@@ -429,22 +429,25 @@ sub getwd() {
return $pwd;
}
+sub is_sha1 {
+ my $s = shift;
+ return $s =~ /^[a-f0-9]{40}$/;
+}
-sub get_headref($$) {
+sub get_headref ($$) {
my $name = shift;
my $git_dir = shift;
- my $sha;
- if (open(C,"$git_dir/refs/heads/$name")) {
- chomp($sha = <C>);
- close(C);
- length($sha) == 40
- or die "Cannot get head id for $name ($sha): $!\n";
+ my $f = "$git_dir/refs/heads/$name";
+ if(open(my $fh, $f)) {
+ chomp(my $r = <$fh>);
+ is_sha1($r) or die "Cannot get head id for $name ($r): $!";
+ return $r;
}
- return $sha;
+ die "unable to open $f: $!" unless $! == POSIX::ENOENT;
+ return undef;
}
-
-d $git_tree
or mkdir($git_tree,0777)
or die "Could not create $git_tree: $!";
@@ -561,90 +564,67 @@ #---------------------
my $state = 0;
-my($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
-my(@old,@new,@skipped);
-sub commit {
- my $pid;
-
+sub update_index (\@\@) {
+ my $old = shift;
+ my $new = shift;
open(my $fh, '|-', qw(git-update-index -z --index-info))
or die "unable to open git-update-index: $!";
print $fh
(map { "0 0000000000000000000000000000000000000000\t$_\0" }
- @old),
+ @$old),
(map { '100' . sprintf('%o', $_->[0]) . " $_->[1]\t$_->[2]\0" }
- @new)
+ @$new)
or die "unable to write to git-update-index: $!";
close $fh
or die "unable to write to git-update-index: $!";
$? and die "git-update-index reported error: $?";
- @old = @new = ();
+}
- $pid = open(C,"-|");
- die "Cannot fork: $!" unless defined $pid;
- unless($pid) {
- exec("git-write-tree");
- die "Cannot exec git-write-tree: $!\n";
- }
- chomp(my $tree = <C>);
- length($tree) == 40
- or die "Cannot get tree id ($tree): $!\n";
- close(C)
+sub write_tree () {
+ open(my $fh, '-|', qw(git-write-tree))
+ or die "unable to open git-write-tree: $!";
+ chomp(my $tree = <$fh>);
+ is_sha1($tree)
+ or die "Cannot get tree id ($tree): $!";
+ close($fh)
or die "Error running git-write-tree: $?\n";
print "Tree ID $tree\n" if $opt_v;
+ return $tree;
+}
- my $parent = "";
- if(open(C,"$git_dir/refs/heads/$last_branch")) {
- chomp($parent = <C>);
- close(C);
- length($parent) == 40
- or die "Cannot get parent id ($parent): $!\n";
- print "Parent ID $parent\n" if $opt_v;
- }
-
- my $pr = IO::Pipe->new() or die "Cannot open pipe: $!\n";
- my $pw = IO::Pipe->new() or die "Cannot open pipe: $!\n";
- $pid = fork();
- die "Fork: $!\n" unless defined $pid;
- unless($pid) {
- $pr->writer();
- $pw->reader();
- open(OUT,">&STDOUT");
- dup2($pw->fileno(),0);
- dup2($pr->fileno(),1);
- $pr->close();
- $pw->close();
-
- my @par = ();
- @par = ("-p",$parent) if $parent;
-
- # loose detection of merges
- # based on the commit msg
- foreach my $rx (@mergerx) {
- if ($logmsg =~ $rx) {
- my $mparent = $1;
- if ($mparent eq 'HEAD') { $mparent = $opt_o };
- if ( -e "$git_dir/refs/heads/$mparent") {
- $mparent = get_headref($mparent, $git_dir);
- push @par, '-p', $mparent;
- print OUT "Merge parent branch: $mparent\n" if $opt_v;
- }
- }
+my($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
+my(@old,@new,@skipped);
+sub commit {
+ update_index(@old, @new);
+ @old = @new = ();
+ my $tree = write_tree();
+ my $parent = get_headref($last_branch, $git_dir);
+ print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $opt_v;
+
+ my @commit_args;
+ push @commit_args, ("-p", $parent) if $parent;
+
+ # loose detection of merges
+ # based on the commit msg
+ foreach my $rx (@mergerx) {
+ next unless $logmsg =~ $rx && $1;
+ my $mparent = $1 eq 'HEAD' ? $opt_o : $1;
+ if(my $sha1 = get_headref($mparent, $git_dir)) {
+ push @commit_args, '-p', $mparent;
+ print "Merge parent branch: $mparent\n" if $opt_v;
}
-
- exec("env",
- "GIT_AUTHOR_NAME=$author_name",
- "GIT_AUTHOR_EMAIL=$author_email",
- "GIT_AUTHOR_DATE=".strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date)),
- "GIT_COMMITTER_NAME=$author_name",
- "GIT_COMMITTER_EMAIL=$author_email",
- "GIT_COMMITTER_DATE=".strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date)),
- "git-commit-tree", $tree,@par);
- die "Cannot exec git-commit-tree: $!\n";
-
- close OUT;
}
- $pw->writer();
- $pr->reader();
+
+ my $commit_date = strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date));
+ my $pid = open2(my $commit_read, my $commit_write,
+ 'env',
+ "GIT_AUTHOR_NAME=$author_name",
+ "GIT_AUTHOR_EMAIL=$author_email",
+ "GIT_AUTHOR_DATE=$commit_date",
+ "GIT_COMMITTER_NAME=$author_name",
+ "GIT_COMMITTER_EMAIL=$author_email",
+ "GIT_COMMITTER_DATE=$commit_date",
+ 'git-commit-tree', $tree, @commit_args);
# compatibility with git2cvs
substr($logmsg,32767) = "" if length($logmsg) > 32767;
@@ -656,16 +636,14 @@ sub commit {
@skipped = ();
}
- print $pw "$logmsg\n"
+ print($commit_write "$logmsg\n") && close($commit_write)
or die "Error writing to git-commit-tree: $!\n";
- $pw->close();
- print "Committed patch $patchset ($branch ".strftime("%Y-%m-%d %H:%M:%S",gmtime($date)).")\n" if $opt_v;
- chomp(my $cid = <$pr>);
- length($cid) == 40
- or die "Cannot get commit id ($cid): $!\n";
+ print "Committed patch $patchset ($branch $commit_date)\n" if $opt_v;
+ chomp(my $cid = <$commit_read>);
+ is_sha1($cid) or die "Cannot get commit id ($cid): $!\n";
print "Commit ID $cid\n" if $opt_v;
- $pr->close();
+ close($commit_read);
waitpid($pid,0);
die "Error running git-commit-tree: $?\n" if $?;
--
1.3.3.g3408
^ permalink raw reply related
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-23 7:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pzh6wtr.fsf@assigned-by-dhcp.cox.net>
[cc'd to list to get reactions on open2]
On Tue, May 23, 2006 at 12:10:08AM -0700, Junio C Hamano wrote:
> > + return $s =~ /^[a-zA-Z0-9]{40}$/;
> [0-9a-f] (We always do lowercase).
Er, yes, that was a complete think-o on my part.
> Hmm. I personally do not have problems with open2, but folks on
> some other platforms might. I'll see how the list audience
> sounds.
FWIW, it was already being used in git-cvsimport.
-Peff
^ permalink raw reply
* [PATCH 1/2] cvsimport: use git-update-index --index-info
From: Jeff King @ 2006-05-23 7:01 UTC (permalink / raw)
To: Martin Langhoff, Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <20060523065810.GB6180@coredump.intra.peff.net>
This should reduce the number of git-update-index forks required per
commit. We now do adds/removes in one call, and we are no longer forced to
deal with argv limitations.
---
Oops, apparently using a mail reader is too challenging for me. Here's a
repost with the headers correctly merged.
cb6452bbfda9c52ad8dbeaac6e3440ae61099a05
git-cvsimport.perl | 36 +++++++++++++-----------------------
1 files changed, 13 insertions(+), 23 deletions(-)
cb6452bbfda9c52ad8dbeaac6e3440ae61099a05
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index d257e66..4efb0a5 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -565,29 +565,19 @@ my($patchset,$date,$author_name,$author_
my(@old,@new,@skipped);
sub commit {
my $pid;
- while(@old) {
- my @o2;
- if(@old > 55) {
- @o2 = splice(@old,0,50);
- } else {
- @o2 = @old;
- @old = ();
- }
- system("git-update-index","--force-remove","--",@o2);
- die "Cannot remove files: $?\n" if $?;
- }
- while(@new) {
- my @n2;
- if(@new > 12) {
- @n2 = splice(@new,0,10);
- } else {
- @n2 = @new;
- @new = ();
- }
- system("git-update-index","--add",
- (map { ('--cacheinfo', @$_) } @n2));
- die "Cannot add files: $?\n" if $?;
- }
+
+ open(my $fh, '|-', qw(git-update-index --index-info))
+ or die "unable to open git-update-index: $!";
+ print $fh
+ (map { "0 0000000000000000000000000000000000000000\t$_\n" }
+ @old),
+ (map { '100' . sprintf('%o', $_->[0]) . " $_->[1]\t$_->[2]\n" }
+ @new)
+ or die "unable to write to git-update-index: $!";
+ close $fh
+ or die "unable to write to git-update-index: $!";
+ $? and die "git-update-index reported error: $?";
+ @old = @new = ();
$pid = open(C,"-|");
die "Cannot fork: $!" unless defined $pid;
--
1.3.3.gcb64-dirty
^ permalink raw reply related
* [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-23 7:00 UTC (permalink / raw)
To: Martin Langhoff, Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <20060523065232.GA6180@coredump.intra.peff.net>
This change attempts to clean up the commit function to make it a bit
easier to read (or at least the first half of it). It also improves
robustness and performance. Specifically:
- report get_headref errors on opening ref unless the error is ENOENT
- use regex to check for sha1 instead of length
- use lexically scoped filehandles which get cleaned up automagically
- check for error on both 'print' and 'close' (since output is buffered)
- avoid "fork, do some perl, then exec" in commit(). It's not necessary,
and we probably end up COW'ing parts of the perl process. Plus the code
is much smaller because we can use open2()
- avoid calling strftime over and over (mainly a readability cleanup)
---
I know this patch is quite large. I can try to split it if you want, but
I suspect it's not worth the effort (either you like refactoring or you
don't :) ).
9dc9f05ab5e1cbd8765238e7b1da0addd6f4296a
git-cvsimport.perl | 150 ++++++++++++++++++++++------------------------------
1 files changed, 64 insertions(+), 86 deletions(-)
9dc9f05ab5e1cbd8765238e7b1da0addd6f4296a
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 4efb0a5..f8feb52 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -23,7 +23,7 @@ use File::Basename qw(basename dirname);
use Time::Local;
use IO::Socket;
use IO::Pipe;
-use POSIX qw(strftime dup2);
+use POSIX qw(strftime dup2 :errno_h);
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
@@ -429,22 +429,25 @@ sub getwd() {
return $pwd;
}
+sub is_sha1 {
+ my $s = shift;
+ return $s =~ /^[a-zA-Z0-9]{40}$/;
+}
-sub get_headref($$) {
+sub get_headref ($$) {
my $name = shift;
my $git_dir = shift;
- my $sha;
- if (open(C,"$git_dir/refs/heads/$name")) {
- chomp($sha = <C>);
- close(C);
- length($sha) == 40
- or die "Cannot get head id for $name ($sha): $!\n";
+ my $f = "$git_dir/refs/heads/$name";
+ if(open(my $fh, $f)) {
+ chomp(my $r = <$fh>);
+ is_sha1($r) or die "Cannot get head id for $name ($r): $!";
+ return $r;
}
- return $sha;
+ die "unable to open $f: $!" unless $! == POSIX::ENOENT;
+ return undef;
}
-
-d $git_tree
or mkdir($git_tree,0777)
or die "Could not create $git_tree: $!";
@@ -561,90 +564,67 @@ #---------------------
my $state = 0;
-my($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
-my(@old,@new,@skipped);
-sub commit {
- my $pid;
-
+sub update_index (\@\@) {
+ my $old = shift;
+ my $new = shift;
open(my $fh, '|-', qw(git-update-index --index-info))
or die "unable to open git-update-index: $!";
print $fh
(map { "0 0000000000000000000000000000000000000000\t$_\n" }
- @old),
+ @$old),
(map { '100' . sprintf('%o', $_->[0]) . " $_->[1]\t$_->[2]\n" }
- @new)
+ @$new)
or die "unable to write to git-update-index: $!";
close $fh
or die "unable to write to git-update-index: $!";
$? and die "git-update-index reported error: $?";
- @old = @new = ();
+}
- $pid = open(C,"-|");
- die "Cannot fork: $!" unless defined $pid;
- unless($pid) {
- exec("git-write-tree");
- die "Cannot exec git-write-tree: $!\n";
- }
- chomp(my $tree = <C>);
- length($tree) == 40
- or die "Cannot get tree id ($tree): $!\n";
- close(C)
+sub write_tree () {
+ open(my $fh, '-|', qw(git-write-tree))
+ or die "unable to open git-write-tree: $!";
+ chomp(my $tree = <$fh>);
+ is_sha1($tree)
+ or die "Cannot get tree id ($tree): $!";
+ close($fh)
or die "Error running git-write-tree: $?\n";
print "Tree ID $tree\n" if $opt_v;
+ return $tree;
+}
- my $parent = "";
- if(open(C,"$git_dir/refs/heads/$last_branch")) {
- chomp($parent = <C>);
- close(C);
- length($parent) == 40
- or die "Cannot get parent id ($parent): $!\n";
- print "Parent ID $parent\n" if $opt_v;
- }
-
- my $pr = IO::Pipe->new() or die "Cannot open pipe: $!\n";
- my $pw = IO::Pipe->new() or die "Cannot open pipe: $!\n";
- $pid = fork();
- die "Fork: $!\n" unless defined $pid;
- unless($pid) {
- $pr->writer();
- $pw->reader();
- open(OUT,">&STDOUT");
- dup2($pw->fileno(),0);
- dup2($pr->fileno(),1);
- $pr->close();
- $pw->close();
-
- my @par = ();
- @par = ("-p",$parent) if $parent;
-
- # loose detection of merges
- # based on the commit msg
- foreach my $rx (@mergerx) {
- if ($logmsg =~ $rx) {
- my $mparent = $1;
- if ($mparent eq 'HEAD') { $mparent = $opt_o };
- if ( -e "$git_dir/refs/heads/$mparent") {
- $mparent = get_headref($mparent, $git_dir);
- push @par, '-p', $mparent;
- print OUT "Merge parent branch: $mparent\n" if $opt_v;
- }
- }
+my($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
+my(@old,@new,@skipped);
+sub commit {
+ update_index(@old, @new);
+ @old = @new = ();
+ my $tree = write_tree();
+ my $parent = get_headref($last_branch, $git_dir);
+ print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $opt_v;
+
+ my @commit_args;
+ push @commit_args, ("-p", $parent) if $parent;
+
+ # loose detection of merges
+ # based on the commit msg
+ foreach my $rx (@mergerx) {
+ next unless $logmsg =~ $rx && $1;
+ my $mparent = $1 eq 'HEAD' ? $opt_o : $1;
+ if(my $sha1 = get_headref($mparent, $git_dir)) {
+ push @commit_args, '-p', $mparent;
+ print "Merge parent branch: $mparent\n" if $opt_v;
}
-
- exec("env",
- "GIT_AUTHOR_NAME=$author_name",
- "GIT_AUTHOR_EMAIL=$author_email",
- "GIT_AUTHOR_DATE=".strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date)),
- "GIT_COMMITTER_NAME=$author_name",
- "GIT_COMMITTER_EMAIL=$author_email",
- "GIT_COMMITTER_DATE=".strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date)),
- "git-commit-tree", $tree,@par);
- die "Cannot exec git-commit-tree: $!\n";
-
- close OUT;
}
- $pw->writer();
- $pr->reader();
+
+ my $commit_date = strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date));
+ my $pid = open2(my $commit_read, my $commit_write,
+ 'env',
+ "GIT_AUTHOR_NAME=$author_name",
+ "GIT_AUTHOR_EMAIL=$author_email",
+ "GIT_AUTHOR_DATE=$commit_date",
+ "GIT_COMMITTER_NAME=$author_name",
+ "GIT_COMMITTER_EMAIL=$author_email",
+ "GIT_COMMITTER_DATE=$commit_date",
+ 'git-commit-tree', $tree, @commit_args);
# compatibility with git2cvs
substr($logmsg,32767) = "" if length($logmsg) > 32767;
@@ -656,16 +636,14 @@ sub commit {
@skipped = ();
}
- print $pw "$logmsg\n"
+ print($commit_write "$logmsg\n") && close($commit_write)
or die "Error writing to git-commit-tree: $!\n";
- $pw->close();
- print "Committed patch $patchset ($branch ".strftime("%Y-%m-%d %H:%M:%S",gmtime($date)).")\n" if $opt_v;
- chomp(my $cid = <$pr>);
- length($cid) == 40
- or die "Cannot get commit id ($cid): $!\n";
+ print "Committed patch $patchset ($branch $commit_date)\n" if $opt_v;
+ chomp(my $cid = <$commit_read>);
+ is_sha1($cid) or die "Cannot get commit id ($cid): $!\n";
print "Commit ID $cid\n" if $opt_v;
- $pr->close();
+ close($commit_read);
waitpid($pid,0);
die "Error running git-commit-tree: $?\n" if $?;
--
1.3.3.gcb64-dirty
^ permalink raw reply related
* Re: irc usage..
From: Jeff King @ 2006-05-23 6:58 UTC (permalink / raw)
To: Martin Langhoff, Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <20060523065232.GA6180@coredump.intra.peff.net>
>From nobody Mon Sep 17 00:00:00 2001
From: Jeff King <peff@peff.net>
Date: Tue, 23 May 2006 01:16:07 -0400
Subject: [PATCH 1/2] cvsimport: use git-update-index --index-info
This should reduce the number of git-update-index forks required per
commit. We now do adds/removes in one call, and we are no longer forced to
deal with argv limitations.
---
cb6452bbfda9c52ad8dbeaac6e3440ae61099a05
git-cvsimport.perl | 36 +++++++++++++-----------------------
1 files changed, 13 insertions(+), 23 deletions(-)
cb6452bbfda9c52ad8dbeaac6e3440ae61099a05
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index d257e66..4efb0a5 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -565,29 +565,19 @@ my($patchset,$date,$author_name,$author_
my(@old,@new,@skipped);
sub commit {
my $pid;
- while(@old) {
- my @o2;
- if(@old > 55) {
- @o2 = splice(@old,0,50);
- } else {
- @o2 = @old;
- @old = ();
- }
- system("git-update-index","--force-remove","--",@o2);
- die "Cannot remove files: $?\n" if $?;
- }
- while(@new) {
- my @n2;
- if(@new > 12) {
- @n2 = splice(@new,0,10);
- } else {
- @n2 = @new;
- @new = ();
- }
- system("git-update-index","--add",
- (map { ('--cacheinfo', @$_) } @n2));
- die "Cannot add files: $?\n" if $?;
- }
+
+ open(my $fh, '|-', qw(git-update-index --index-info))
+ or die "unable to open git-update-index: $!";
+ print $fh
+ (map { "0 0000000000000000000000000000000000000000\t$_\n" }
+ @old),
+ (map { '100' . sprintf('%o', $_->[0]) . " $_->[1]\t$_->[2]\n" }
+ @new)
+ or die "unable to write to git-update-index: $!";
+ close $fh
+ or die "unable to write to git-update-index: $!";
+ $? and die "git-update-index reported error: $?";
+ @old = @new = ();
$pid = open(C,"-|");
die "Cannot fork: $!" unless defined $pid;
--
1.3.3.gcb64-dirty
^ permalink raw reply related
* Re: irc usage..
From: Jeff King @ 2006-05-23 6:52 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <46a038f90605221615j59583bcdqf128bab31603148e@mail.gmail.com>
On Tue, May 23, 2006 at 11:15:07AM +1200, Martin Langhoff wrote:
> >I think cvsimport predates that option, but these days that loop
> >can be optimized by feeding --index-info from standard input.
> Oh, yep, that'd be a good addition. I think we can also cut down on
This patch is relatively simple, and I'll post it in a moment.
I also made a few other cleanups to commit() which apply on top of that;
I'll post it also.
> - Stop abusing globals in commit() -- pass the commit data as parameters.
Some of the globals actually get modified in commit() (e.g., @old and
@new get cleared). So we need to either pass them in as references or
remember to do that cleanup each time it is called (which is really only
twice, I think).
> Will be trying to do those things in the next few days, don't mind if
> someone jumps in as well.
I can look at the line/block CVS file slurping, but not tonight.
-Peff
^ permalink raw reply
* Re: [PATCH] git status: ignore empty directories (because they cannot be added)
From: Matthias Lederhofer @ 2006-05-23 5:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vu07h8rzr.fsf@assigned-by-dhcp.cox.net>
> > and a new option -u / --untracked-files to show files in untracked
> > directories.
> >
> > ---
> > A few things I'm not sure about:
> > - Should there be another option to disable --no-empty-directory?
>
> I am not sure about this. We used to show everything in a
> directory full of untracked directory, which was distracting and
> that was the reason we added --directory there. Maybe it would
> be less confusing if we just updated the message
>
> print "#\n# Untracked files:\n";
> print "# (use \"git add\" to add to commit)\n";
> print "#\n";
>
> to say "use 'git add' on these files and files in these
> directories you wish to add", or something silly like that,
> without this patch?
I do not know if I understand you correctly, do you want to leave out
the -u part of the patch or the whole patch?
Well, anyway, here the reasons for this patch:
- Working in a git repository with a lot of empty directories is
annoying, because all of them show up in git status even though they
cannot be added. With --no-empty-directories they are hidden.
- If there is a directory which may be added because it is quite
useful to have the -u option to see what is in there to add (without
using ls path/to/directory).
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Jason Riedy @ 2006-05-23 4:51 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: Git Mailing List
In-Reply-To: <f3d7535d0605222020j2d581bd9j602752659a4b3ac2@mail.gmail.com>
And "Stefan Pfetzing" writes:
- printf ("access: %d\n", access("/etc/motd", X_OK));
[...]
- will return 0 on solaris - when run as root, even though /etc/motd
- is not executeable.
This is explicitly allowed by the SUS, even for non-root:
http://www.opengroup.org/onlinepubs/000095399/functions/access.html
For non-root, some ACL systems could allow you to execute
the file even if there are no execute bits. What a joy
ACLs are. Or NFS uid mappings could play tricks on you,
or... And as you've noticed, this kills [ -x ]. (Failing
to run the hooks in receive-pack.c is noisy but not fatal.
It's the shell scripts that stop.)
I think you're stuck. To disable the hooks for all possible
users, OSes, file systems, etc., you need to remove them.
Or just don't run as root, and hope that the OS isn't
completely insane.
BTW, ERR_RUN_COMMAND_EXEC is never returned. Any failure
to exec will produce an exit code of 128 from die. This
will be an issue when commit becomes a built-in, right?
Jason
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Stefan Pfetzing @ 2006-05-23 3:20 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <6471.1147883724@lotus.CS.Berkeley.EDU>
Hi Jason,
2006/5/17, Jason Riedy <ejr@eecs.berkeley.edu>:
> And pkgsrc itself works just fine without the silly g prefix,
> or at least does for me as a mere user (and as well as it does
> work). But if you intend on adding the package upstream, it'll
> need something to cope with the g. And pkgsrc handles local
> patches...
Well I had some problems on NetBSD without the g prefix for the
gnu coreutils - since then I always used that prefix.
But now I have a completely different problem with the tests on
solaris. It seems on solaris access() always returns 0 if a file is
existant and the effective uid is 0.
so:
--- snip ---
#include <stdio.h>
#include <unistd.h>
int
main (int argc, char **argv)
{
printf ("access: %d\n", access("/etc/motd", X_OK));
return 0;
}
--- snap ---
will return 0 on solaris - when run as root, even though /etc/motd
is not executeable. This seems to break hooks on Solaris - but
I'm not sure if this is only a Solaris Express bug. (I have no Solaris
10 system to verify it)
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Martin Langhoff (CatalystIT) @ 2006-05-23 3:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Git Mailing List, Junio C Hamano, Johannes.Schindelin, spyderous,
smurf
In-Reply-To: <Pine.LNX.4.64.0605221926270.3697@g5.osdl.org>
Linus Torvalds wrote:
>
> This stupid patch on top of yours seems to make git happier. It's
> disgusting, I know, but it just repacks things every kilo-commit.
>
> I actually think that I found a real ext3 performance bug from trying to
> determine why git sometimes slows down ridiculously when the tree has been
> allowed to go too long without a repack.
>
Acked (in case anyone cares for such an obvious one), and thanks! I
thought of doing that last night together with that exact patch, but I
was focussing on the leak.
cheers,
m
--
-----------------------------------------------------------------------
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] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Linus Torvalds @ 2006-05-23 2:28 UTC (permalink / raw)
To: Martin Langhoff
Cc: Git Mailing List, Junio C Hamano, Johannes.Schindelin, spyderous,
smurf
In-Reply-To: <11482978883713-git-send-email-martin@catalyst.net.nz>
This stupid patch on top of yours seems to make git happier. It's
disgusting, I know, but it just repacks things every kilo-commit.
I actually think that I found a real ext3 performance bug from trying to
determine why git sometimes slows down ridiculously when the tree has been
allowed to go too long without a repack.
Linus
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index fb56278..c141f5e 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -853,10 +853,14 @@ # VERSION:1.96->1.96.2.1
} elsif($state == 9 and /^\s*$/) {
$state = 10;
} elsif(($state == 9 or $state == 10) and /^-+$/) {
- if ($opt_L && $commitcount++ >= $opt_L) {
+ $commitcount++;
+ if ($opt_L && $commitcount > $opt_L) {
last;
}
commit();
+ if (($commitcount & 1023) == 0) {
+ system("git repack -a -d");
+ }
$state = 1;
} elsif($state == 11 and /^-+$/) {
$state = 1;
^ permalink raw reply related
* Re: [PATCH] Change GIT-VERSION-GEN to call git commands with "git" not "git-".
From: Junio C Hamano @ 2006-05-23 1:20 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP09B22AA86724B4F2C01F7FAE9A0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> GIT-VERSION-GEN can incorrectly return a default version of
> "v1.3.GIT" because it tries to execute git commands using the
> "git-cmd" format that expects all git commands to be in the $PATH.
> Convert these to "git cmd" format so that a proper answer is
> returned even when the git commands have been moved out of the
> $PATH and into a $gitexecdir.
IIRC, the reason we spelled it as "git-describe"
with a dash is ancient git wrapper said "not a git command" when
given "describe" which it did not understand without failing.
I think it has been long enough since we introduced "git describe",
so this would be OK.
^ permalink raw reply
* Re: [PATCH] git status: ignore empty directories (because they cannot be added)
From: Junio C Hamano @ 2006-05-23 1:11 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FiHXS-0008MC-LB@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> and a new option -u / --untracked-files to show files in untracked
> directories.
>
> ---
> A few things I'm not sure about:
> - Should there be another option to disable --no-empty-directory?
I am not sure about this. We used to show everything in a
directory full of untracked directory, which was distracting and
that was the reason we added --directory there. Maybe it would
be less confusing if we just updated the message
print "#\n# Untracked files:\n";
print "# (use \"git add\" to add to commit)\n";
print "#\n";
to say "use 'git add' on these files and files in these
directories you wish to add", or something silly like that,
without this patch?
^ permalink raw reply
* Re: [PATCH] Avoid segfault in diff --stat rename output.
From: Junio C Hamano @ 2006-05-23 1:02 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP115C9137E5BDABD705881BAE9B0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> ---
> diff.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 7f35e59..a7bb9b9 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -237,7 +237,7 @@ static char *pprint_rename(const char *a
> if (a_midlen < 0) a_midlen = 0;
> if (b_midlen < 0) b_midlen = 0;
>
> - name = xmalloc(len_a + len_b - pfx_length - sfx_length + 7);
> + name = xmalloc(pfx_length + a_midlen + b_midlen + sfx_length + 7);
> sprintf(name, "%.*s{%.*s => %.*s}%s",
Obviously correct given what the sprintf() that immediately
follows does. Sheesh, what was I smoking back then. *BLUSH*
Thanks.
^ permalink raw reply
* [PATCH] Avoid segfault in diff --stat rename output.
From: Sean @ 2006-05-23 0:36 UTC (permalink / raw)
To: Torgil Svensson; +Cc: git
In-Reply-To: <e7bda7770605221609h7c18c2ccpe92db34050d46f9f@mail.gmail.com>
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On Tue, 23 May 2006 01:09:43 +0200
"Torgil Svensson" <torgil.svensson@gmail.com> wrote:
> Hi
>
> It seems like git-diff-tree has some problems with moved files:
>
> $ git-diff-tree -p --stat --summary -M
> 348f179e3195448cea49c98a79cce8c7f446ce26
> 343ca16424ba031b37e4df49afddaee098a8f347 | wc -l
> *** glibc detected *** free(): invalid pointer: 0x12ecbbf0 ***
> 6101
diff --git a/diff.c b/diff.c
index 7f35e59..a7bb9b9 100644
--- a/diff.c
+++ b/diff.c
@@ -237,7 +237,7 @@ static char *pprint_rename(const char *a
if (a_midlen < 0) a_midlen = 0;
if (b_midlen < 0) b_midlen = 0;
- name = xmalloc(len_a + len_b - pfx_length - sfx_length + 7);
+ name = xmalloc(pfx_length + a_midlen + b_midlen + sfx_length + 7);
sprintf(name, "%.*s{%.*s => %.*s}%s",
pfx_length, a,
a_midlen, a + pfx_length,
--
1.3.GIT
^ permalink raw reply related
* cogito testsuite failure - git-read-tree too careful
From: Pavel Roskin @ 2006-05-23 0:28 UTC (permalink / raw)
To: Petr Baudis, git
Hello, Petr!
The testsuite for cogito fails in t9300-seek.sh for up-to-date master
branches of git and Cogito.
$ ./t9300-seek.sh -v -i
* expecting success: cg-seek cbd273f56aecaaf28b857ae74da77cbb11a4d659
Warning: uncommitted local changes, trying to bring them along
fatal: Entry 'newdir/newfile' not uptodate. Cannot merge.
cg-seek: cbd273f56aecaaf28b857ae74da77cbb11a4d659: bad commit
* FAIL 21: seeking to the first commit
cg-seek cbd273f56aecaaf28b857ae74da77cbb11a4d659
As I understand it, "git-read-tree -m" in cg-Xlib refuses to merge if
there are local changes. This was likely caused by commit
fcc387db9bc453dc7e07a262873481af2ee9e5c8:
read-tree -m -u: do not overwrite or remove untracked working tree
files.
I guess git-read-tree should be using "--reset" or something to restore
the original behavior.
The "tutorial" testsuite also fails:
Should not be doing an Octopus.
No merge strategy handled the merge.
Merging 5de8995e58b4b478dff476788c3607ed5021fc24 ->
ba8b9edd80500d60d68a6630ee415a3e710f6db2
to a60f36f73018dc1959d8d2cbd28271f93ee5f686 ...
fatal: Untracked working tree file 'stack.h' would be overwritten by
merge.
cg-merge: git-read-tree failed (merge likely blocked by local changes)
162
?
Unexpected error 4 on line 242
In this case, we may want cg-merge to fail, because it's wrong to
overwrite local files without backing them up.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Linus Torvalds @ 2006-05-23 0:02 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, BjEngelmann, git
In-Reply-To: <BAYC1-PASMTP1164FE2A24B4D1B4C0A607AE9A0@CEZ.ICE>
On Mon, 22 May 2006, Sean wrote:
> What seems to becoming clear as more people find new ways to use
> git is that many of them would be well served by having a solid
> infrastructure to handle metadata. Consider the case above: _git_
> itself doesn't need a structural reference, but users and external
> applications definitely need to be able to lookup which metadata
> is associated with any given commit. Having a git standard for
> this type of data would help. Tags already do this, so they're
> likely to be used and abused in ways not initially envisioned,
> just because git doesn't have another such facility.
I definitely think we should allow arbitrary tags.
That said, I think that what you actually want to do may be totally
different.
If _each_ commit has some extra information associated with it, you don't
want to create a tag that points to the commit, you more likely want to
create an object that is indexed by the commit ID rather than the other
way around.
IOW, I _think_ that what you described would be that if you have the
commit ID, you want to find the data based on that ID. No?
And that you can do quite easily, while _also_ using git to distribute the
extra per-commit meta-data. Just create a separate branch that has the
data indexed by commit ID. That could be as simple as having one file per
commit (using, perhaps, a similar directory layout as the .git/objects/
directory itself), and then you could do something like
# Get the SHA1 of the named commit
commit=$(git-rev-parse --verify "$cmitname"^0)
# turn it into a filename (slash between two first chars and the rest)
filename=$(echo $commit | sed 's:^\(..\)\(.*\):\1/\2:')
# look it up in the "annotations" branch
git cat-file blob "annotations:$filename"
which gets the data from the "annotations" branch, indexed by the SHA1
name.
Now, everybody can track your "annotations" branch using git, and get your
per-commit annotations for the main branch.
See?
The real advantage of tags is that you can use them for the SHA1
expressions, and follow them automatically. If that's what you want (ie
you don't want to index things by the commit SHA1, but by some external
name, like the name the commit had in some other repository), then by all
means use tags. But if you just want to associate some data with each
commit, the above "separate branch for annotations" approach is much more
efficient.
Linus
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 23:33 UTC (permalink / raw)
To: Martin Langhoff
Cc: Matthias Urlichs, Donnie Berkholz, Yann Dirson, Git Mailing List,
Johannes Schindelin
In-Reply-To: <46a038f90605221623g25325e71hf3faf0a6a6ca628a@mail.gmail.com>
On Tue, 23 May 2006, Martin Langhoff wrote:
>
> I really don't think that using the local cvs binary is a problem at
> all. In my experience, the thing is fairly fast and optimized when you
> ask it to perform file-oriented questions and that's all we do,
> really.
Fair enough. My worry was mainly that the cvs server was doing something
stupid, but I suspect most of the fork/exec's are probably from the
cvsimport perl script itself.
> In any case, we have it already -- parsecvs does it quite well (modulo
> memory leaks!) and I've used it several times in conjunction with
> cvsimport. Just perform the initial import with parsecvs and then
> 'track' the remote project with cvsimport.
I didn't get parsecvs working when I tried it a long time ago, and Donnie
reported that it ran out of memory, so I didn't even really consider it.
I'd love for it to work well, and it may be reasonable to do really big
imports on multi-gigabyte 64-bit machines (after all, they aren't _hard_
to find any more, and you only need to do it once).
That said, it still seems pretty stupid to require that much memory just
to import from CVS.
Linus
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-22 23:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthias Urlichs, Donnie Berkholz, Yann Dirson, Git Mailing List,
Johannes Schindelin
In-Reply-To: <46a038f90605221623g25325e71hf3faf0a6a6ca628a@mail.gmail.com>
On 5/23/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> The problem is that they lead to slightly different trees.
Sorry! s/trees/histories/ there. The trees are (or should!) be the
same, and tree differences should be addressed as bugs. Differences in
how history is parsed are unavoidable right now.
martin
^ permalink raw reply
* Re: Local clone/fetch with cogito is glacial
From: Petr Baudis @ 2006-05-22 23:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Sean, git
In-Reply-To: <Pine.LNX.4.64.0605221615030.3697@g5.osdl.org>
> The git-clone script will literally special-case rsync:// and http://.
> Everything else should work fine with git-fetch-pack.
Aha, I overlooked that what I described goes on in git-clone happens
only with git-clone -l, otherwise it indeed seems to use git-fetch-pack.
Sorry about the confusion.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-22 23:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthias Urlichs, Donnie Berkholz, Yann Dirson, Git Mailing List,
Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0605221516500.3697@g5.osdl.org>
On 5/23/06, Linus Torvalds <torvalds@osdl.org> wrote:
> I don't think the remote usability is valid, except for some really small
> repositories. The fact that it takes hours even when the CVS server is
> local doesn't bode well for doing it remotely for any but the most trivial
> things.
I really don't think that using the local cvs binary is a problem at
all. In my experience, the thing is fairly fast and optimized when you
ask it to perform file-oriented questions and that's all we do,
really.
If you want to try it, you'll see that local checkouts of large trees
(like this gentoo one) are fairly fast. Not as fast as GIT itself, but
good enough. I think Donnie has hit a bug with a bad version of cvs,
but other than that, my experience with it is that it is fairly well
behaved -- even if the tool is bad, ubiquity has lead to resiliency
over the years.
> I really think it would be better to have local use be the optimized case,
> with remote being the "it's _possible_" case.
Agreed, but I think we won't see much benefit in direct parsing. And
we'll have to take the hit of double-implementation.
In any case, we have it already -- parsecvs does it quite well (modulo
memory leaks!) and I've used it several times in conjunction with
cvsimport. Just perform the initial import with parsecvs and then
'track' the remote project with cvsimport.
The problem is that they lead to slightly different trees. So their
output is not consistent, and I don't think that'll be easy to fix.
cheers,
martin
^ permalink raw reply
* Re: Local clone/fetch with cogito is glacial
From: Linus Torvalds @ 2006-05-22 23:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Sean, git
In-Reply-To: <20060522225054.GL11941@pasky.or.cz>
On Tue, 23 May 2006, Petr Baudis wrote:
>
> Even rsync and HTTP cg-clones? git:// and git+ssh:// fetching follows an
> almost entirely different code patch and it's much more efficient since
> I just accumulate the tag object ids I want to check and then pour them
> to git-fetch-pack - I cannot do that with git-(local|http)-fetch. :-(
Sure you can. Well, not to http-fetch, but git-fetch-pack should work fine
for a local repo.
The git-clone script will literally special-case rsync:// and http://.
Everything else should work fine with git-fetch-pack.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Sean @ 2006-05-22 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: BjEngelmann, git
In-Reply-To: <7vac99c1hv.fsf@assigned-by-dhcp.cox.net>
On Mon, 22 May 2006 12:18:04 -0700
Junio C Hamano <junkio@cox.net> wrote:
> Now, about the usage of such a long tag for your purpose.
>
> As you noticed, commits and tags are the only types of objetcs
> that can refer to other commits structurally. But there are
> cases where you do not even need nor want structural reference.
> For example, 'git cherry-pick' records the commit object name of
> the cherry-picked commit in the commit message as part of the
> text -- such a commit does not have structural reference to the
> original commit, and we would not _want_ one. I have a strong
> suspicion that your application does not need or want structural
> reference to commits, and it might be better to merely mention
> their object names as part of the text the application produces,
> just like what 'git cherry-pick' does.
What seems to becoming clear as more people find new ways to use
git is that many of them would be well served by having a solid
infrastructure to handle metadata. Consider the case above: _git_
itself doesn't need a structural reference, but users and external
applications definitely need to be able to lookup which metadata
is associated with any given commit. Having a git standard for
this type of data would help. Tags already do this, so they're
likely to be used and abused in ways not initially envisioned,
just because git doesn't have another such facility.
> Presumably you will have one such tag per commit, and by default
> 'fetch' (both cg and git) tries to follow tags, which means
> anybody who fetches new revision would automatically download
> this QA data -- that is one implication of using a tag to store
> this information. Without knowing the nature of it, I am not
> sure if everybody who tracks the source wants such baggage. If
> not, then use of a tag for this may not be appropriate.
Right. It would be much nicer if it was possible to request or
ignore specific types of metadata when fetching; yet another
reason that it would be great if git had something built in
which anticipated this need.
> Another question is if the QA data expected to be amended or
> annotated later, after it is created.
>
> If the answer is yes, then you probably would not want tags --
> you can create a new tag that points at the same commit to
> update the data, but then you have no structural relationships
> given by git between such tags that point at the same commit.
> You could infer their order by timestamp but that is about it.
> I think you are better off creating a separate QA project that
> adds one new file per commit on the main project, and have the
> file identify the commit object on the main project (either
> start your text file format for QA data with the commit object
> name, or name each such QA data file after the commit object
> name). Then your automated procedure could scan and add a new
> file to the QA project every time a new commit is made to the
> main project, and the data in the QA project can be amended or
> annotated and the changes will be version controlled.
There are a lot of nice features with using a separate meta-data
branch. However, you lose the ability to do lookups like you can
with tags. A tag like index that gave the ability to associate
commits on otherwise unrelated branches might be a way to get
the best of both worlds. However, there will be times where
version controlled meta-data is overkill. Just need to codify a
git-standard for meta data, so that git can help where possible.
> If the answer is no, then it is probably better to just use an
> append-only log file that textually records which entry
> corresponds to which commit in the project. If it is not
> version controlled, and if it is not part of the main project, I
> do not see much point in putting the data under git control and
> in the same project.
It would be very nice if git gave a standard way to lookup and
perhaps even display metadata. Could add an option to git log
for example that said, show all metadata of a certain type.
There are a limitless number of examples where people want to
associate extra information with each commit. Other SCM's call
these "attributes" or have other such names. Given git's design
it isn't too hard to imagine offering the ability for version
controlled (or not) and public (or not) meta-data. Very similar
to tags, but perhaps with a few extra features.
If git already offered this feature, there'd be no need for a
flat-file ref-log; the data could be stored in a git-standard
way for metadata and gain the features of whatever tools grow
up around it, like querying, inspecting, purging etc.. All of
a sudden people would be able to look at (and perhaps even update)
their own meta data via git log/qgit/gitk/gitweb etc.. All we
need is a standard that everyone can conform with.
Sean
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-22 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Urlichs, git
In-Reply-To: <7v8xotadm3.fsf@assigned-by-dhcp.cox.net>
On 5/23/06, Junio C Hamano <junkio@cox.net> wrote:
> > I simply was too lazy to count the actual filenames' lengths. ;-)
>
> I think cvsimport predates that option, but these days that loop
> can be optimized by feeding --index-info from standard input.
Oh, yep, that'd be a good addition. I think we can also cut down on
the number of fork+exec calls (as Linus points out they are killing
us) by caching some data we should already have that we are repeatedly
asking from git-ref-parse.
Other TODOs from my reading of the code last night...
- Switch from line-oriented reads to block reads when fetching files
from CVS. This gentoo has repo has some large binary blobs in it and
we end up slurping them into memory.
- Stop abusing globals in commit() -- pass the commit data as parameters.
- Further profiling? Whatever we are doing, we aren't doing it fast :(
Will be trying to do those things in the next few days, don't mind if
someone jumps in as well.
martin
^ 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