* 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
* Re: Fix branch ancestry calculation
From: Keith Packard @ 2006-03-25 7:54 UTC (permalink / raw)
To: Chris Shoemaker
Cc: keithp, Linus Torvalds, David Mansfield, David Mansfield,
Git Mailing List
In-Reply-To: <20060325014532.GB32522@pe.Belkin>
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On Fri, 2006-03-24 at 20:45 -0500, Chris Shoemaker wrote:
> If that last sentence was a typo then you already know this, but
> otherwise you may be disappointed to learn that it's not _always_
> possible to discern the correct ancestry tree.
Sure, it's possible to generate trees which can't be figured out. So
far, I haven't found any which can't be pieced back together, except in
cases where the tree was accidentally damaged (child branches created on
two separate parent branches)
> If you end up comparing the ancestry tree discovered by your tool and
> the tree output by a patched cvsps, I would be very interested in the
> results.
So far, I've found several concrete trees where cvsps (in any form)
assigns branch points many versions too early compared to the 'true'
history. My tool is getting better answers, but still can't compute the
tree for the X.org X server tree yet. That one has a wide variety of
damage, including the direct copying of ,v files between repositories
which had divered, and the accidental branching of files from different
parent branches. I keep poking at it...
> -chris
>
> (*) You can distinguish between A->B->head and B->A->head simply by
> date.
I'm doing a lot more date-based identification than I'm really
comfortable with; the bad thing here is that branch points can occur
long before any commits to that branch, when doing date-based
operations, you have a range of possible matching branch points and it's
hard to disambiguate.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Junio C Hamano @ 2006-03-25 7:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vk6ajxbe5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> This uses a simplified libxdiff setup to generate unified diffs _without_
>> doing fork/execve of GNU "diff".
>
> Good stuff.
The reason I like this is because I was thinking about doing
in-core diffs for different purpose when I was driving to work
this morning [*1*] --- to make pickaxe a more useful building
block.
Currently, pickaxe tries to do an exact match to find the case
where a given substring S appears in the version C of the file
but not in the its parent C^n (1 <= n), and then it tells the
diffcore to emit the differences. The user (probably only me on
this list?) is expected to look at the change, make an
intelligent decision to feed a matching substring S' found in
C^n and restart from that commit.
To be a useful "content movement tracker", the process of
finding matching 'old shape' in the previous version and
re-feeding it to pickaxe should be automated if possible, and
in-core diff machinery would be one component to help that.
For example, if I wanted to find when I stole 'ls-files -t'
feature from Cogito, I would first run less ls-files.c; I see
these and am reasonably sure these relate to what I am looking
for:
...
static const char *tag_cached = "";
static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified = "";
...
So I run:
$ git whatchanged -S'static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified' -p master -- ls-files.c
which finds:
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Sep 19 15:11:15 2005 -0700
Show modified files in git-ls-files
...
@@ -28,6 +29,7 @@ static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
+static const char *tag_modified = "";
but that is not what I am interested in; the matching "old
shape" is the version before the tag_modified was added (and it
already had other tag_xxx in there). So with the current
pickaxe, I manually re-run whatchanged starting from the found
commit with modified string like this:
$ git whatchanged -S'static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";' -p $that_commit -- ls-files.c
in order to further drill down.
A truly useful pickaxe should take two line numbers and a
filename (to name the range of lines I am interested in) from
the starting version, notice when that range changes shape, and
after showing the found commit, replace the range with the one
matching from the older commit and continue.
[Footnote]
*1* When you are bogged down in a boring day-job, your brain
tends to try to compensate by spending as much your waking time
as possible on thinking about more interesting and more useful
stuff -- like git ;-).
^ permalink raw reply
* Re: Effective difference between git-rebase and git-resolve
From: Junio C Hamano @ 2006-03-25 7:15 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20060325063225.GA13791@buici.com>
Marc Singer <elf@buici.com> writes:
[I'm shuffling this part to the top]
> Moreover, it isn't clear to me if git-rebase is better than git-merge.
Merge preserves commit ancestry, so if you are hoping it to
clean up your history, that is not the tool to do it. Both
rebase and cherry-pick are to help you create a cleaner,
alternate history. So none is better than the other. They
serve different purposes.
> On Fri, Mar 24, 2006 at 10:08:09PM -0800, Junio C Hamano wrote:
>> > Junio, is there some magic to restart a rebase after you've fixed up the
>> > conflicts?
>>
>> The modern rebase is essentially git-format-patch piped to
>> git-am (with -3 flag to allow falling back to three-way merge),
>> and all the familiar "the patch did not apply -- what now?"
>> techniques can be employed.
>...
> By modern do you mean newer than 1.2.4? I comprehend what you're
> layin' down here, but I don't know if I need to do something
> different.
By modern, I meant v0.99.9-g7f59dbb.
diff-tree 7f59dbb... (from f9039f3...)
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Nov 14 00:41:53 2005 -0800
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Junio C Hamano @ 2006-03-25 6:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603241938510.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This uses a simplified libxdiff setup to generate unified diffs _without_
> doing fork/execve of GNU "diff".
Good stuff.
> Now, in the interest of full disclosure, I should also point out a few
> downsides:
>
> - the libxdiff algorithm is different,...
>
> - 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.
That's kind of sad --- Documentation/SubmittingPatches request
people to say "diff -u -p".
> - 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.
Another thing I noticed is that while libxdiff always shows full
line counts "-n,m +l,k" GNU seems to omit them when it can (m,k
<=1). I am not sure if apply.c is set up to grok what libxdiff
emits correctly. Running t/t1200 shows some obvious examples.
^ 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