* Re: Use a *real* built-in diff generator
From: Linus Torvalds @ 2006-03-25 15:56 UTC (permalink / raw)
To: Morten Welinder; +Cc: Junio C Hamano, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.64.0603250734130.15714@g5.osdl.org>
On Sat, 25 Mar 2006, Linus Torvalds wrote:
>
> I'll be taking a look at trying to fix it.
Actually, it ended up being easier than I expected it to be.
This (on top of the previous patch) should fix it.
And yes, with this, I can pass the output of
git diff v2.6.16..
to "git-apply" and it not only passes the "--stat" thing (which verifies
that git-apply is happy with the diff) but it also results in exactly the
same tree when applied on top of v2.6.16 (and the patch has two cases
where the "no newline" test triggers).
The speed-up is quite noticeable, especially when doing things like
git diff v2.6.16.. | git-apply --stat
which just _used_ to be painfully slow (25 seconds for me) and is now
under five seconds. That's the difference between "twiddling your thumbs"
and "ok, that wasn't too bad".
Now, to be honest, the real reason I wanted a built-in diff wasn't the
speed advantage, but the fact that it's so much more flexible. The lack of
fork/exec just allows us to do things that weren't practical before.
Linus
----
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 01e6765..b68afa2 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -31,14 +31,22 @@
int xdl_emit_diffrec(char const *rec, long size, char const *pre, long psize,
xdemitcb_t *ecb) {
- mmbuffer_t mb[2];
+ mmbuffer_t mb[3];
+ int i;
mb[0].ptr = (char *) pre;
mb[0].size = psize;
mb[1].ptr = (char *) rec;
mb[1].size = size;
+ i = 2;
- if (ecb->outf(ecb->priv, mb, 2) < 0) {
+ if (!size || rec[size-1] != '\n') {
+ mb[2].ptr = "\n\\ No newline at end of file\n";
+ mb[2].size = strlen(mb[2].ptr);
+ i = 3;
+ }
+
+ if (ecb->outf(ecb->priv, mb, i) < 0) {
return -1;
}
^ permalink raw reply related
* Re: Use a *real* built-in diff generator
From: Linus Torvalds @ 2006-03-25 15:36 UTC (permalink / raw)
To: Morten Welinder; +Cc: Junio C Hamano, Git Mailing List, Davide Libenzi
In-Reply-To: <118833cc0603250544h289f385fo683ec7b40cdb0ed@mail.gmail.com>
On Sat, 25 Mar 2006, Morten Welinder wrote:
>
> The primary correctness concern is that patch understands
> the output, ie., the libxdiff + patch brings out right back.
>
> It ought to be fairly easy to script checking every file change
> that ever went into a git repository. You won't cover evil
> cases that way, but it should provide some assurances that
> nothing is too wrong.
I did _some_ tests, and especially "git-apply" is very useful, since it is
actually a lot more anal than regular "patch".
It all worked fine except for files that don't end with a newline. Davide
points out that he just forces the EOLN at the end in his test harness,
but that's not exactly acceptable for a real project that actually has
real cases.
I'll be taking a look at trying to fix it.
Linus
^ permalink raw reply
* Re: [PATCH 3/4] send-email: lazy-load Email::Valid and make it optional
From: Randal L. Schwartz @ 2006-03-25 15:07 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git, Ryan Anderson, Greg KH
In-Reply-To: <11432834111972-git-send-email-normalperson@yhbt.net>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> +my $have_email_valid = eval { require Email::Valid or undef };
This is not necessary... if eval fails, it returns undef by definition. Your
code presumes that the non-zero last-expression-evaluated of a require is also
returned from the require, which I believe is only accidentally true, although
the behavior may be recently documented and therefore promised. (On perl 5.8,
it looks a bit fishy to me at a quick glance.)
My favorite idiom for a possibly failing eval-step is:
my $can_I_do_this = eval { riskything; 1 };
If riskything fails, eval returns undef. If it succeeds, it evaluates the 1,
and returns that.
--
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: Use a *real* built-in diff generator
From: Morten Welinder @ 2006-03-25 13:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.64.0603241938510.15714@g5.osdl.org>
The primary correctness concern is that patch understands
the output, ie., the libxdiff + patch brings out right back.
It ought to be fairly easy to script checking every file change
that ever went into a git repository. You won't cover evil
cases that way, but it should provide some assurances that
nothing is too wrong.
M.
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Alex Riesen @ 2006-03-25 12:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.64.0603241938510.15714@g5.osdl.org>
On 3/25/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> This uses a simplified libxdiff setup to generate unified diffs _without_
> doing fork/execve of GNU "diff".
>
> This has several huge advantages, for example:
>
Even more impressive on Cygwin (>50x!):
.../git-win$ time git --exec-path=$(pwd) diff initial.. > /dev/null
real 0m1.485s
user 0m0.567s
sys 0m0.840s
../git-win$ time git diff initial.. >/dev/null
real 1m20.781s
user 0m31.806s
sys 0m20.717s
^ permalink raw reply
* [PATCH] Add git-explode-packs
From: Martin Atukunda @ 2006-03-25 12:02 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
This script does the opposite of git repack -a -d.
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
.gitignore | 1 +
Documentation/git-explode-packs.txt | 45 +++++++++++++++++++++++++++++++++++
Makefile | 2 +-
git-explode-packs.sh | 26 ++++++++++++++++++++
4 files changed, 73 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-explode-packs.txt
create mode 100755 git-explode-packs.sh
277352dd9a0549cd626242b14454da37acbc72f3
diff --git a/.gitignore b/.gitignore
index b4355b9..0ac74e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -133,3 +133,4 @@ libgit.a
*.py[co]
config.mak
git-blame
+git-explode-packs
diff --git a/Documentation/git-explode-packs.txt b/Documentation/git-explode-packs.txt
new file mode 100644
index 0000000..9651a4e
--- /dev/null
+++ b/Documentation/git-explode-packs.txt
@@ -0,0 +1,45 @@
+git-explode-packs(1)
+====================
+
+NAME
+----
+git-explode-packs - Script used to explode packs in a repository into objects
+
+
+SYNOPSIS
+--------
+'git-explode-packs'
+
+DESCRIPTION
+-----------
+
+This script is used to explode all packs into the constituent objects.
+
+A pack is a collection of objects, individually compressed, with
+delta compression applied, stored in a single file, with an
+associated index file.
+
+Packs are used to reduce the load on mirror systems, backup
+engines, disk storage, etc.
+
+This script removes all the packs in the repository, replacing them with the
+objects that are stored inside them.
+
+Author
+------
+Written by Martin Atukunda <matlads@dsmagic.com>
+
+Documentation
+--------------
+Documentation by Martin Atukunda <matlads@dsmag.com>
+
+See Also
+--------
+gitlink:git-pack-objects[1]
+gitlink:git-prune-packed[1]
+gitlink:git-repack[1]
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index 8d45378..71e31f0 100644
--- a/Makefile
+++ b/Makefile
@@ -125,7 +125,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh git-grep.sh \
- git-lost-found.sh
+ git-lost-found.sh git-explode-packs.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-explode-packs.sh b/git-explode-packs.sh
new file mode 100755
index 0000000..a7e9761
--- /dev/null
+++ b/git-explode-packs.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Martin Atukunda
+#
+
+USAGE=''
+. git-sh-setup
+
+PACKDIR="$GIT_OBJECT_DIRECTORY/pack"
+PRESDIR="./++preserve"
+
+mkdir "$PRESDIR" && (
+ for p in "$GIT_OBJECT_DIRECTORY"/pack/pack-*.pack; do
+ if test -f "$p"; then
+ mv "$p" "$PRESDIR"
+ fi
+ done
+
+ for p in "$PRESDIR"/pack-*.pack; do
+ if test -f "$p"; then
+ git-unpack-objects <$p
+ rm -- $p
+ fi
+ done
+ rmdir "$PRESDIR"
+)
--
1.2.4.gd3e1
^ permalink raw reply related
* Re: Effective difference between git-rebase and git-resolve
From: Johannes Schindelin @ 2006-03-25 11:26 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne2a94r.cp6.mdw@metalzone.distorted.org.uk>
Hi,
On Sat, 25 Mar 2006, Mark Wooding wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > I am nowhere near kernel people, but I am using git on a machine where it
> > is too cumbersome to install python. If git-resolve goes, I am without a
> > merge strategy (at least until git-recursive is ported to C... was that
> > not the plan with git-merge-tree? What happened on that front?).
>
> Err... git-resolve isn't the same as git-merge-resolve.
Oooops.
Thank you,
Dscho
^ permalink raw reply
* Re: Effective difference between git-rebase and git-resolve
From: Mark Wooding @ 2006-03-25 11:08 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0603251034550.14457@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I am nowhere near kernel people, but I am using git on a machine where it
> is too cumbersome to install python. If git-resolve goes, I am without a
> merge strategy (at least until git-recursive is ported to C... was that
> not the plan with git-merge-tree? What happened on that front?).
Err... git-resolve isn't the same as git-merge-resolve. The latter is a
stupid merge strategy which fits into the git-merge/git-pull
infrastructure. The former is a different program which does merges
badly, and you didn't want to use it even if you don't have Python!
I'd forgotten all about git-resolve until it got mentioned just now.
-- [mdw]
^ permalink raw reply
* [PATCH] send-email: try to order messages in email clients more correctly
From: Eric Wong @ 2006-03-25 11:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Greg KH, Ryan Anderson, Eric Wong
If --no-chain-reply-to is set, patches may not always be ordered
correctly in email clients. This patch makes sure each email
sent from a different second.
I chose to start with a time (slightly) in the past because
those are probably more likely in real-world usage and spam
filters might be more tolerant of them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
695849a185ee8cfc8f3df0c737ff16a04cc84a5b
diff --git a/git-send-email.perl b/git-send-email.perl
index 207b1fb..de635ed 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -37,7 +37,7 @@ sub cleanup_compose_files();
my $compose_filename = ".msg.$$";
# Variables we fill in automatically, or via prompting:
-my (@to,@cc,@initial_cc,$initial_reply_to,$initial_subject,@files,$from,$compose);
+my (@to,@cc,@initial_cc,$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
# Behavior modification variables
my ($chain_reply_to, $smtp_server, $quiet, $suppress_from, $no_signed_off_cc) = (1, "localhost", 0, 0, 0);
@@ -295,13 +295,14 @@ sub make_message_id
$cc = "";
+$time = time - scalar $#files;
sub send_message
{
my @recipients = unique_email_list(@to);
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc);
- my $date = strftime('%a, %d %b %Y %H:%M:%S %z', localtime(time));
+ my $date = strftime('%a, %d %b %Y %H:%M:%S %z', localtime($time++));
my $header = "From: $from
To: $to
--
1.2.4.gb622a
^ permalink raw reply related
* Perserving permissions?
From: Jeff Garzik @ 2006-03-25 10:48 UTC (permalink / raw)
To: Git Mailing List
I just started using git to maintain some of my server config files.
Leagues better than subversion, which I was previously using, but git
still suffers from a key problem that subversion also has: lack of
permission preservation.
I understand that versioning permissions might be a big request, but
what about simply storing the permissions at 'git add' time, to be used
at checkout time?
Right now I have to do 'git pull ; ./fix-perms' each time I update.
Jeff
^ permalink raw reply
* [PATCH 4/4] send-email: add support for mutt aliases files
From: Eric Wong @ 2006-03-25 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson, Greg KH, Eric Wong
In-Reply-To: <11432834101430-git-send-email-normalperson@yhbt.net>
I got rid of the Email::Valid dependency since writing
RFC-correct email addresses is probably not a problem for most
users.
In my experience, misspelled usernames are a much bigger
problem. I am prone to doing things like leaving out the 'k' in
Junio's email address and other things that Email::Valid can't
catch.
Since I use mutt and the aliases file is pretty simple, I've
added basic support for mutt alias files.
To setup git-send-email to use a mutt aliases file for a repo,
do this:
git-repo-config sendemail.muttaliases <mutt_alias_file_path>
More email clients/address book formats can easily be supported
in the future.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
8bc65d178dd755ecd1f3c038b975b9bbe58c1015
diff --git a/git-send-email.perl b/git-send-email.perl
index 73bba19..207b1fb 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -89,6 +89,15 @@ sub gitvar_ident {
my ($author) = gitvar_ident('GIT_AUTHOR_IDENT');
my ($committer) = gitvar_ident('GIT_COMMITTER_IDENT');
+my %aliases;
+if (my $mutt_aliases = `git-repo-config sendemail.muttaliases`) {
+ chomp $mutt_aliases;
+ open my $ma, '<', $mutt_aliases or die "opening $mutt_aliases: $!\n";
+ while (<$ma>) { if (/^alias\s+(\S+)\s+(.*)/) { $aliases{$1} = $2 } }
+ close $ma;
+}
+# aliases for more mail clients can be supported here:
+
my $prompting = 0;
if (!defined $from) {
$from = $author || $committer;
@@ -112,6 +121,9 @@ if (!@to) {
$prompting++;
}
+@to = map { $aliases{$_} || $_ } @to;
+@initial_cc = map { $aliases{$_} || $_ } @initial_cc;
+
if (!defined $initial_subject && $compose) {
do {
$_ = $term->readline("What subject should the emails start with? ",
--
1.2.4.gb622a
^ permalink raw reply related
* [PATCH 2/4] send-email: use built-in time() instead of /bin/date '+%s'
From: Eric Wong @ 2006-03-25 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson, Greg KH, Eric Wong
In-Reply-To: <11432834101430-git-send-email-normalperson@yhbt.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
079ce058710240643369589448660620cd925f5c
diff --git a/git-send-email.perl b/git-send-email.perl
index efaf457..5e08817 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -264,8 +264,7 @@ my $message_id_template = "<%s-git-send-
sub make_message_id
{
- my $date = `date "+\%s"`;
- chomp($date);
+ my $date = time;
my $pseudo_rand = int (rand(4200));
$message_id = sprintf $message_id_template, "$date$pseudo_rand";
#print "new message id = $message_id\n"; # Was useful for debugging
--
1.2.4.gb622a
^ permalink raw reply related
* [PATCH 3/4] send-email: lazy-load Email::Valid and make it optional
From: Eric Wong @ 2006-03-25 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson, Greg KH, Eric Wong
In-Reply-To: <11432834101430-git-send-email-normalperson@yhbt.net>
It's not installed on enough machines, and is overkill most of
the time. We'll fallback to a very basic regexp (that is a
looser variant of what Email::Valid allows) just in case, but
nothing like the monster regexp Email::Valid has to offer :)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
140eaf9b9d438ea489e6c72e2148feb3e355aea8
diff --git a/git-send-email.perl b/git-send-email.perl
index 5e08817..73bba19 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -22,12 +22,12 @@ use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
use Net::SMTP;
-use Email::Valid;
# most mail servers generate the Date: header, but not all...
$ENV{LC_ALL} = 'C';
use POSIX qw/strftime/;
+my $have_email_valid = eval { require Email::Valid or undef };
my $smtp;
sub unique_email_list(@);
@@ -250,6 +250,16 @@ EOT
# Variables we set as part of the loop over files
our ($message_id, $cc, %mail, $subject, $reply_to, $message);
+sub extract_valid_address {
+ my $address = shift;
+ if ($have_email_valid) {
+ return Email::Valid->address($address);
+ } else {
+ # less robust/correct than the monster regexp in Email::Valid,
+ # but still does a 99% job, and one less dependency
+ return ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
+ }
+}
# Usually don't need to change anything below here.
@@ -259,7 +269,7 @@ our ($message_id, $cc, %mail, $subject,
# 1 second since the last time we were called.
# We'll setup a template for the message id, using the "from" address:
-my $message_id_from = Email::Valid->address($from);
+my $message_id_from = extract_valid_address($from);
my $message_id_template = "<%s-git-send-email-$message_id_from>";
sub make_message_id
@@ -412,7 +422,7 @@ sub unique_email_list(@) {
my @emails;
foreach my $entry (@_) {
- my $clean = Email::Valid->address($entry);
+ my $clean = extract_valid_address($entry);
next if $seen{$clean}++;
push @emails, $entry;
}
--
1.2.4.gb622a
^ permalink raw reply related
* send-email: dependency removal, cleanup, + small feature
From: Eric Wong @ 2006-03-25 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson, Greg KH
1 - Change from Mail::Sendmail to Net::SMTP
2 - use built-in time() instead of /bin/date '+%s'
3 - lazy-load Email::Valid and make it optional
4 - add support for mutt aliases files
Patches 1 and 3 make git-send-email easily runnable with any
reasonable Perl installation. 2 is just a good idea. 4 makes
my life a lot easier.
--
Eric Wong
^ permalink raw reply
* [PATCH 1/4] send-email: Change from Mail::Sendmail to Net::SMTP
From: Eric Wong @ 2006-03-25 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson, Greg KH, Eric Wong
In-Reply-To: <11432834101430-git-send-email-normalperson@yhbt.net>
Net::SMTP is in the base Perl distribution, so users are more
likely to have it. Net::SMTP also allows reusing the SMTP
connection, so sending multiple emails is faster.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 66 ++++++++++++++++++++++++++++++++-------------------
1 files changed, 41 insertions(+), 25 deletions(-)
7155ae6e5f94a8fdf55f50029af27279dd36fd0a
diff --git a/git-send-email.perl b/git-send-email.perl
index b220d11..efaf457 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -19,11 +19,17 @@
use strict;
use warnings;
use Term::ReadLine;
-use Mail::Sendmail qw(sendmail %mailcfg);
use Getopt::Long;
use Data::Dumper;
+use Net::SMTP;
use Email::Valid;
+# most mail servers generate the Date: header, but not all...
+$ENV{LC_ALL} = 'C';
+use POSIX qw/strftime/;
+
+my $smtp;
+
sub unique_email_list(@);
sub cleanup_compose_files();
@@ -271,35 +277,45 @@ $cc = "";
sub send_message
{
- my $to = join (", ", unique_email_list(@to));
-
- %mail = ( To => $to,
- From => $from,
- CC => $cc,
- Subject => $subject,
- Message => $message,
- 'Reply-to' => $from,
- 'In-Reply-To' => $reply_to,
- 'Message-ID' => $message_id,
- 'X-Mailer' => "git-send-email",
- );
-
- $mail{smtp} = $smtp_server;
- $mailcfg{mime} = 0;
-
- #print Data::Dumper->Dump([\%mail],[qw(*mail)]);
-
- sendmail(%mail) or die $Mail::Sendmail::error;
+ my @recipients = unique_email_list(@to);
+ my $to = join (",\n\t", @recipients);
+ @recipients = unique_email_list(@recipients,@cc);
+ my $date = strftime('%a, %d %b %Y %H:%M:%S %z', localtime(time));
+
+ my $header = "From: $from
+To: $to
+Cc: $cc
+Subject: $subject
+Reply-To: $from
+Date: $date
+Message-Id: $message_id
+X-Mailer: git-send-email
+";
+ $header .= "In-Reply-To: $reply_to\n" if $reply_to;
+
+ $smtp ||= Net::SMTP->new( $smtp_server );
+ $smtp->mail( $from ) or die $smtp->message;
+ $smtp->to( @recipients ) or die $smtp->message;
+ $smtp->data or die $smtp->message;
+ $smtp->datasend("$header\n$message") or die $smtp->message;
+ $smtp->dataend() or die $smtp->message;
+ $smtp->ok or die "Failed to send $subject\n".$smtp->message;
if ($quiet) {
- printf "Sent %s\n", $subject;
+ print "Sent $subject\n";
} else {
- print "OK. Log says:\n", $Mail::Sendmail::log;
- print "\n\n"
+ print "OK. Log says:
+Date: $date
+Server: $smtp_server Port: 25
+From: $from
+Subject: $subject
+Cc: $cc
+To: $to
+
+Result: ", $smtp->code, ' ', ($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
}
}
-
$reply_to = $initial_reply_to;
make_message_id();
$subject = $initial_subject;
@@ -390,7 +406,7 @@ sub cleanup_compose_files() {
}
-
+$smtp->quit if $smtp;
sub unique_email_list(@) {
my %seen;
--
1.2.4.gb622a
^ permalink raw reply related
* Re: Bug encountered while comitting
From: Matthias Kestenholz @ 2006-03-25 10:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtejxd3u.fsf@assigned-by-dhcp.cox.net>
* Junio C Hamano (junkio@cox.net) wrote:
> You are right. commit-tree does not seem to check if it
> successfully wrote the commit object. How about this?
>
> -- >8 --
> diff --git a/commit-tree.c b/commit-tree.c
> index 88871b0..16c1787 100644
> --- a/commit-tree.c
> +++ b/commit-tree.c
> @@ -125,7 +125,10 @@ int main(int argc, char **argv)
> while (fgets(comment, sizeof(comment), stdin) != NULL)
> add_buffer(&buffer, &size, "%s", comment);
>
> - write_sha1_file(buffer, size, "commit", commit_sha1);
> - printf("%s\n", sha1_to_hex(commit_sha1));
> - return 0;
> + if (!write_sha1_file(buffer, size, "commit", commit_sha1)) {
> + printf("%s\n", sha1_to_hex(commit_sha1));
> + return 0;
> + }
> + else
> + return 1;
> }
This patch fixes the problem I was encountering (git-update-ref is
not executed anymore).
Thank you all for this really great tool!
--
:wq
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Jan-Benedict Glaw @ 2006-03-25 10:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4424443F.5090209@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]
On Fri, 2006-03-24 20:10:55 +0100, Andreas Ericsson <ae@op5.se> wrote:
> Jan-Benedict Glaw wrote:
> >On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> >wrote:
> >
> >Since it seems nobody looked at the GCC import run (which means to use
> >the svnimport), I ran it again, under strace control:
>
> If you send me a bzipped tar-ball of the repo you're trying to import,
> preferrably with all the patches to cvsps you've tried, I'll see what I
> can do over the weekend.
It's the regular SVN-based sources of GCC at their upstream location.
In their CVS timeline, they had the repository rsync'able, but I guess
with SVN we only get access through the SVN server.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] External diff viewer
From: Marco Costalba @ 2006-03-25 9:50 UTC (permalink / raw)
To: git
I have just pushed a patch to let qgit support external diff viewers.
Git repo is
http://digilander.libero.it/mcostalba/scm/qgit.git
This is how it works:
>From menu View->'External diff' it is possible to invoke an external
diff viewer, as example to view the diffs in a two vertical tiled
windows.
External diff viewer shows the diffs between two files.
First file is the current selected file of current revision. Second
file is the same file of the parent revision or of a specific revision
if "diff to selected sha" feature is enabled (CTRL + RIGHT CLICK on
chosen revision with *internal* diff viewer window open).
Default external viewer is kompare, but it is possible to set a
preferred one from Edit->Settings->External Diff Viewer.
I don't think the feature is already release ready, so I just pushed
the patch in git repo for interested people.
Feedback/comments /bugs or something to change or improve before to release?
Thanks
Marco
^ permalink raw reply
* [PATCH] Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-25 9:39 UTC (permalink / raw)
To: git; +Cc: pasky
In-Reply-To: <20060325093641.GA26284@coredump.intra.peff.net>
tree_timewarp was calling read, egrep, and rm in an O(N) loop where N is
the number of changed files between two trees. This caused a bottleneck
when seeking/switching/merging between trees with many changed files.
Signed-off-by: Jeff King <peff@peff.net>
---
This is a repost of the initial patch featuring a few cleanups suggested
by Junio.
cg-Xlib | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
5f79b37a0eb85ff4f643e70a7f2823e68e9d9ca4
diff --git a/cg-Xlib b/cg-Xlib
index 5896df7..1a9bd4f 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -363,12 +363,9 @@ tree_timewarp()
# Kill gone files
git-diff-tree -r "$base" "$branch" |
- while IFS=$'\t' read header file; do
- # match ":100755 000000 14d43b1abf... 000000000... D"
- if echo "$header" | egrep "^:([^ ][^ ]* ){4}D" >/dev/null; then
- rm -- "$file"
- fi
- done
+ # match ":100755 000000 14d43b1abf... 000000000... D"
+ sed -ne 's/^:[^\t]* D\t//p' |
+ xargs rm -f --
git-checkout-index -u -f -a
# FIXME: Can produce bogus "contains only garbage" messages.
--
1.2.4
^ permalink raw reply related
* Re: Effective difference between git-rebase and git-resolve
From: Johannes Schindelin @ 2006-03-25 9:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v1wwrys07.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 24 Mar 2006, Junio C Hamano wrote:
> If nobody in the upper echelon of kernel people (meaning, longest-time
> git users) use git-resolve anymore, I think we should mark it deprecated
> and remove it eventually.
I am nowhere near kernel people, but I am using git on a machine where it
is too cumbersome to install python. If git-resolve goes, I am without a
merge strategy (at least until git-recursive is ported to C... was that
not the plan with git-merge-tree? What happened on that front?).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-25 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060324164352.GA20684@spearce.org>
On Fri, Mar 24, 2006 at 11:43:52AM -0500, Shawn Pearce wrote:
> Now that I think about it isn't this sort of where you were before
> in cg-seek?
Yes, that's basically it. Short of Junio explaining how the manual file
removal can be avoided, I think my original patch should be applied, as
it causes an order of magnitude speed up. I will repost the cleaned-up
version.
-Peff
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Marco Costalba @ 2006-03-25 9:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.64.0603241938510.15714@g5.osdl.org>
On 3/25/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> This uses a simplified libxdiff setup to generate unified diffs _without_
> doing fork/execve of GNU "diff".
>
> This has several huge advantages, for example:
>
> Before:
>
> [torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null
>
> real 0m24.818s
> user 0m13.332s
> sys 0m8.664s
>
> After:
>
> [torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null
>
> real 0m4.563s
> user 0m2.944s
> sys 0m1.580s
>
Currently 'getting the diffs' is the second most important time
consumer of annotation calculation (just after getting the file
history). On big and heavily modified files, as drivers/net/tg3.c in
Linux tree, this can be very slow (around 10s on my box).
The profiling has been done on qgit, but I think it is of general
interest because qgit uses git-rev-list and git-diff-tree -p to get
file's history and diffs respectively.
So this patch is more then welcomed! Thanks!
Marco
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: James Cloos @ 2006-03-25 9:10 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060322133337.GU20746@lug-owl.de>
Isn't gcc in svn nowadays?
I'd try something like:
rsync://gcc.gnu.org/gcc-svn gcc-svn
git-svnimport -C gcc-git -i -v file:///$(pwd)/gcc-svn
unless you have write access, in which case you may prefer:
mkdir gcc-svn && cd gcc-svn
git-svn init svn+ssh://username@gcc.gnu.org/svn/gcc/trunk
git-svn fetch
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Davide Libenzi @ 2006-03-25 9:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603241938510.15714@g5.osdl.org>
On Fri, 24 Mar 2006, Linus Torvalds wrote:
> - the libxdiff algorithm is different, and I bet GNU diff has gotten a
> lot more testing. And the thing is, generating a diff is not an exact
> science - you can get two different diffs (and you will), and they can
> both be perfectly valid. So it's not possible to "validate" the
> libxdiff output by just comparing it against GNU diff.
Correct, the diff(A, B) is not unique. If you look inside the test
directory, there's an xregression binary that does:
1) Random generate A
2) Create B by random changing A
3) Create D=A-B
4) Verify that B+D==A and A-D==B (using the library patch function)
It does and repeat this operation continuosly, for both text (using text
diff/patch) and binary (using binary diff/patch). It ran several days
w/out finding errors, so I've a good confidence about it.
> - GNU diff does some nice eye-candy, like trying to figure out what the
> last function was, and adding that information to the "@@ .." line.
> libxdiff doesn't do that.
This, I don't think is a natural part of a generic text/binary diff/patch
library. If you feel it is important, you could post-process the diff, but
IMO is kinda bogus.
> - The libxdiff thing has some known deficiencies. In particular, it gets
> the "\No newline at end of file" case wrong. So this is currently for
> the experimental branch only. I hope Davide will help fix it.
This, need fix. At the moment, in my projects I enforce the final EOL if
missing (look inside the file-load function inside the test directory).
> Technical note: this is based on libxdiff-0.17, but I did some surgery to
> get rid of the extraneous fat - stuff that git doesn't need, and seriously
> cutting down on mmfile_t, which had much more capabilities than the diff
> algorithm either needed or used. In this version, "mmfile_t" is just a
> trivial <pointer,length> tuple.
>
> That said, I tried to keep the differences to simple removals, so that you
> can do a diff between this and the libxdiff origin, and you'll basically
> see just things getting deleted. Even the mmfile_t simplifications are
> left in a state where the diffs should be readable.
Here you have two options. Either you suck in the libxdiff code and change
it to drop/change the stuff you don't want (the whole libxdiff library
compiled with -O2 is 33KB though). Or you use the library as is, like
you'd use libz & co. Once you have your own load-mmfile, you can pretty
much feed libxdiff as is. Not my choice though, so pick the one you think
best for your project.
I see you use XDF_NEED_MINIMAL. You might want to do some experiments with
and without, to see how diff size changes, versus time.
> Apologies to Davide, whom I'd love to get feedback on this all from (I
> wrote my own "fill_mmfile()" for the new simpler mmfile_t format: the old
If you look inside the test directory, I use a similar function. The
reason of the mmfile born for a use I made of the library inside an
embedded device where there was no guarantee of contiguos memory, and dat
could have been generated in chunks. OTOH an mmfile with a single block is
a perfectly valid mmfile ;)
PS: Another solution you have is to libify GNU diff by creating a
diff_main() & co., usual libification wrapping. You'd need to change
the exit() that diff throws with a setjmp/longjmp, and make it call
you own mem alloc/free functions, in order to free up memory diff does
not clear on return. I did it once, not many changes. This solution
will give you all the GNU diff crud, like function names, etc...
- Davide
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Eric Wong @ 2006-03-25 8:25 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060324182504.GI31387@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>
> Since it seems nobody looked at the GCC import run (which means to use
> the svnimport), I ran it again, under strace control:
If you don't care for automated branch handling, how about trying git-svn?
under the contrib/ directory in git.git
git-svn init svn://gcc.gnu.org/svn/gcc
git-svn fetch
> > GCC
> > ~~~
> > $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
>
> > Committed change 3936:/ 1993-03-31 05:44:03)
> > Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e
> > Writing to refs/heads/origin
> > DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e
> > ... 3937 trunk/gcc/final.c ...
> > Can't fork at /home/jbglaw/bin/git-svnimport line 379.
>
> ... 4279 trunk/gcc/config/i386/xm-sco.h ...
>
> This time it broke at a different revision, so I guess it's not a SVN
> or git / git-svnimport problem, but rather a problem of my Perl
> installation or the kernel itself?
I've known of SVN library bindings leaking memory in the past, but I
thought it's been solved. Afaik, any memory allocated by the Perl
interpreter is never released back to the kernel, either. (At least
that seems to be the case with my setup (Debian unstable, Perl 5.8.8,
2.6 kernel, x86 machine).
> What are possible reasons for clone() to fail with -ENOMEN? I have to
> admit that the box _is_ loaded a bit all the time:
>
> jbglaw@bixie:~/vax/git-conversion$ uptime
> 19:23:58 up 136 days, 7:46, 20 users, load average: 4.45, 4.25, 3.05
> jbglaw@bixie:~/vax/git-conversion$ free
> total used free shared buffers cached
> Mem: 507308 501760 5548 0 2184 16900
> -/+ buffers/cache: 482676 24632
> Swap: 2441872 1295512 1146360
Some importers (my own git-svn included) aren't amazingly efficient when
handling lots of history which gcc has. It looks like (from what I
understand of the SVN api used in git-svnimport) is that the entire log
for the 100k+ revisions in the tree is slurped down into memory before
any processing is done.
git-svn does this too, but by parsing the output of the svn binary
instead of using the library, so at least it won't have issues with the
svn bindings and libraries to worry about.
My git-svn process running on the SVN tree just finished parsing the svn
log output, and it's maxed out at 74M RSS (on a 32-bit x86). It'll
probably take a while to import it all (which I won't do), but I could
have just as easily done the following to reduce memory usage by ~half:
git-svn fetch -r0:50000 # import the first 50000k
git-svn fetch # now import the remaining
Afaik, there's no way to do something like the above with git-svnimport
for memory-starved setups.
--
Eric Wong
^ 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