* git-svn name
From: Eric Wong @ 2006-03-26 3:04 UTC (permalink / raw)
To: git; +Cc: Gerrit Pape, Chris Wright
I told somebody about my 'git-svn' program, and of course they asked
where they could read about it. Since I don't have a website for it,
I Googled for 'git-svn' in hopes that it'd lead me to
contrib/git-svn/git-svn.txt on gitweb.
To my surprise, I found that git-svn was already packaged for several
major distributions. Of course, it turns out that those binary packages
are actually of git-svnimport. Oops, maybe I should've checked before
naming my own creation git-svn :x
Of course, I still think git-svn is a good name because it describes
what the program does in as little text as possible. If anybody has any
suggestions that don't require too much typing while keeping the name
meaningful, feel free to suggest them.
Would distro package maintainers also be willing to add my git-svn
script to their git-svn binary packages when a new release of git is
made, too? It's quite different from git-svnimport (see
contrib/git-svn/git-svn.txt for details).
--
Eric Wong
^ permalink raw reply
* [PATCH] contrib/git-svn: stabilize memory usage for big fetches
From: Eric Wong @ 2006-03-26 2:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jan-Benedict Glaw, Eric Wong
In-Reply-To: <20060325082521.GA17473@hand.yhbt.net>
We should be safely able to import histories with thousands
of revisions without hogging up lots of memory.
With this, we lose the ability to autocorrect mistakes when
people specify revisions in reverse, but it's probably no longer
a problem since we only have one method of log parsing nowadays.
I've added an extra check to ensure that revision numbers do
increment.
Also, increment the version number to 0.11.0. I really should
just call it 1.0 soon...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 109 ++++++++++++++++++++++++------------------
1 files changed, 63 insertions(+), 46 deletions(-)
c76df6617116a7d330a3110230bc3b01eaf9c66d
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index f3fc3ec..3e5733e 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -8,7 +8,7 @@ use vars qw/ $AUTHOR $VERSION
$GIT_SVN_INDEX $GIT_SVN
$GIT_DIR $REV_DIR/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
-$VERSION = '0.10.0';
+$VERSION = '0.11.0';
$GIT_DIR = $ENV{GIT_DIR} || "$ENV{PWD}/.git";
# make sure the svn binary gives consistent output between locales and TZs:
$ENV{TZ} = 'UTC';
@@ -217,9 +217,8 @@ sub fetch {
push @log_args, '--stop-on-copy' unless $_no_stop_copy;
my $svn_log = svn_log_raw(@log_args);
- @$svn_log = sort { $a->{revision} <=> $b->{revision} } @$svn_log;
- my $base = shift @$svn_log or croak "No base revision!\n";
+ my $base = next_log_entry($svn_log) or croak "No base revision!\n";
my $last_commit = undef;
unless (-d $SVN_WC) {
svn_cmd_checkout($SVN_URL,$base->{revision},$SVN_WC);
@@ -234,18 +233,22 @@ sub fetch {
}
my @svn_up = qw(svn up);
push @svn_up, '--ignore-externals' unless $_no_ignore_ext;
- my $last_rev = $base->{revision};
- foreach my $log_msg (@$svn_log) {
- assert_svn_wc_clean($last_rev, $last_commit);
- $last_rev = $log_msg->{revision};
- sys(@svn_up,"-r$last_rev");
+ my $last = $base;
+ while (my $log_msg = next_log_entry($svn_log)) {
+ assert_svn_wc_clean($last->{revision}, $last_commit);
+ if ($last->{revision} >= $log_msg->{revision}) {
+ croak "Out of order: last >= current: ",
+ "$last->{revision} >= $log_msg->{revision}\n";
+ }
+ sys(@svn_up,"-r$log_msg->{revision}");
$last_commit = git_commit($log_msg, $last_commit, @parents);
+ $last = $log_msg;
}
- assert_svn_wc_clean($last_rev, $last_commit);
+ assert_svn_wc_clean($last->{revision}, $last_commit);
unless (-e "$GIT_DIR/refs/heads/master") {
sys(qw(git-update-ref refs/heads/master),$last_commit);
}
- return pop @$svn_log;
+ return $last;
}
sub commit {
@@ -708,49 +711,61 @@ sub svn_commit_tree {
return fetch("$rev_committed=$commit")->{revision};
}
+# read the entire log into a temporary file (which is removed ASAP)
+# and store the file handle + parser state
sub svn_log_raw {
my (@log_args) = @_;
- my $pid = open my $log_fh,'-|';
+ my $log_fh = IO::File->new_tmpfile or croak $!;
+ my $pid = fork;
defined $pid or croak $!;
-
- if ($pid == 0) {
+ if (!$pid) {
+ open STDOUT, '>&', $log_fh or croak $!;
exec (qw(svn log), @log_args) or croak $!
}
+ waitpid $pid, 0;
+ croak if $?;
+ seek $log_fh, 0, 0 or croak $!;
+ return { state => 'sep', fh => $log_fh };
+}
+
+sub next_log_entry {
+ my $log = shift; # retval of svn_log_raw()
+ my $ret = undef;
+ my $fh = $log->{fh};
- my @svn_log;
- my $state = 'sep';
- while (<$log_fh>) {
+ while (<$fh>) {
chomp;
if (/^\-{72}$/) {
- if ($state eq 'msg') {
- if ($svn_log[$#svn_log]->{lines}) {
- $svn_log[$#svn_log]->{msg} .= $_."\n";
- unless(--$svn_log[$#svn_log]->{lines}) {
- $state = 'sep';
+ if ($log->{state} eq 'msg') {
+ if ($ret->{lines}) {
+ $ret->{msg} .= $_."\n";
+ unless(--$ret->{lines}) {
+ $log->{state} = 'sep';
}
} else {
croak "Log parse error at: $_\n",
- $svn_log[$#svn_log]->{revision},
+ $ret->{revision},
"\n";
}
next;
}
- if ($state ne 'sep') {
+ if ($log->{state} ne 'sep') {
croak "Log parse error at: $_\n",
- "state: $state\n",
- $svn_log[$#svn_log]->{revision},
+ "state: $log->{state}\n",
+ $ret->{revision},
"\n";
}
- $state = 'rev';
+ $log->{state} = 'rev';
# if we have an empty log message, put something there:
- if (@svn_log) {
- $svn_log[$#svn_log]->{msg} ||= "\n";
- delete $svn_log[$#svn_log]->{lines};
+ if ($ret) {
+ $ret->{msg} ||= "\n";
+ delete $ret->{lines};
+ return $ret;
}
next;
}
- if ($state eq 'rev' && s/^r(\d+)\s*\|\s*//) {
+ if ($log->{state} eq 'rev' && s/^r(\d+)\s*\|\s*//) {
my $rev = $1;
my ($author, $date, $lines) = split(/\s*\|\s*/, $_, 3);
($lines) = ($lines =~ /(\d+)/);
@@ -758,36 +773,34 @@ sub svn_log_raw {
/(\d{4})\-(\d\d)\-(\d\d)\s
(\d\d)\:(\d\d)\:(\d\d)\s([\-\+]\d+)/x)
or croak "Failed to parse date: $date\n";
- my %log_msg = ( revision => $rev,
+ $ret = { revision => $rev,
date => "$tz $Y-$m-$d $H:$M:$S",
author => $author,
lines => $lines,
- msg => '' );
+ msg => '' };
if (defined $_authors && ! defined $users{$author}) {
die "Author: $author not defined in ",
"$_authors file\n";
}
- push @svn_log, \%log_msg;
- $state = 'msg_start';
+ $log->{state} = 'msg_start';
next;
}
# skip the first blank line of the message:
- if ($state eq 'msg_start' && /^$/) {
- $state = 'msg';
- } elsif ($state eq 'msg') {
- if ($svn_log[$#svn_log]->{lines}) {
- $svn_log[$#svn_log]->{msg} .= $_."\n";
- unless (--$svn_log[$#svn_log]->{lines}) {
- $state = 'sep';
+ if ($log->{state} eq 'msg_start' && /^$/) {
+ $log->{state} = 'msg';
+ } elsif ($log->{state} eq 'msg') {
+ if ($ret->{lines}) {
+ $ret->{msg} .= $_."\n";
+ unless (--$ret->{lines}) {
+ $log->{state} = 'sep';
}
} else {
croak "Log parse error at: $_\n",
- $svn_log[$#svn_log]->{revision},"\n";
+ $ret->{revision},"\n";
}
}
}
- close $log_fh or croak $?;
- return \@svn_log;
+ return $ret;
}
sub svn_info {
@@ -1114,9 +1127,13 @@ __END__
Data structures:
-@svn_log = array of log_msg hashes
+$svn_log hashref (as returned by svn_log_raw)
+{
+ fh => file handle of the log file,
+ state => state of the log file parser (sep/msg/rev/msg_start...)
+}
-$log_msg hash
+$log_msg hashref as returned by next_log_entry($svn_log)
{
msg => 'whitespace-formatted log entry
', # trailing newline is preserved
--
1.2.4.gb622a
^ permalink raw reply related
* Re: Following renames
From: Junio C Hamano @ 2006-03-26 2:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060326014946.GB18185@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> An obvious solution would be to have git-diff-tree --follow which
> updates its interesting path set based on seen renames, and now that
> I've written about non-linear history, it's obvious that it's incorrect.
> The other obvious way to go is then to add rename detection support to
> git-rev-list, and it's less obvious that this is a dead end too - I
> didn't inspect the code myself yet, but for now I trust Linus in [2]
> (I didn't quite understand the argument, I guess I need to sleep on it).
I'd have to sleep on how the core side can help Porcelains, but
I think it is a good thing that you, one of the most vocal
advocate on the list for doing rename recording, are thinking
about this issue and probably would look into rev-list.c soon.
Looking at the evolution of rev-list.c file itself was a good
exercise to realize that rename tracking (more specifically,
having whatchanged to follow renames) is not such a useful
thing (at least for me).
If I am interested in rev-list.c's evolution from "the set of
command line flags it supported" point of view, then whatchanged
to show the history of rev-list.c file itself would be a very
good way to show that to me. rev-list_usage[] = "..." stayed
there almost from the beginning.
However, if I am interested in the way how it traverses the
commits has changed over time, I would need to start from
revision.c and switch to rev-list.c when that part of the code
was split out from it, because the current rev-list.c does not
have the main part of the traversal logic at all.
Another example. Today's tar-tree updates have one interesting
function I think should belong to strbuf.c, and before merging
it to the mainline, I may move that function from tar-tree.c to
strbuf.c. After that happens, if I run "whatchanged strbuf.c"
to see where that function came from, I would want it to notice
it came from tar-tree.c, although it is not a rename at all.
Just one function moved from a file to another.
What this suggests is that switching the set of paths to follow
while traversing ancestry chain needs to depend on which part of
the original file you are interested in. Marking "this commit
renames (or copies) file A to file B" is not that useful -- for
that matter, detecting at runtime like we currently do is not
better either. If a file A and file B were cleaned up and
merged into a single file C, which is in the tip of the tree,
which one you would want whatchanged to switch following depends
on which part of the C you were interested in.
Unless you are interested in the _entire_ contents of the file,
that is. Then tracking or even recording renames becomes
useful, but that is a special case.
That is the reason I am not so enthused about recording renames.
I think the time is better spent on enhancing what pickaxe tries
to do (currently it does very little), which I hinted in a
separate message late last night.
But that does not have to stop you, and does not have to stop me
from thinking about ways to help you either.
^ permalink raw reply
* Re: [PATCH] send-email: address expansion for common mailers
From: Eric Wong @ 2006-03-26 2:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkuyt2ku.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Two git repo-config keys are required for this
> > (as suggested by Ryan Anderson):
> >
> > sendemail.aliasesfile = <filename of aliases file>
> > sendemail.aliasfiletype = (mutt|gnus|pine|mailrc)
> >
> > I was initially working on auto-detection, but mailrc and mutt formats
> > tend to throw each other off (they're alike, but handle multiple
> > addresses per-alias differently).
>
> I think specifying the type explicitly is probably not too much
> hassle for the end user, so that is fine. Now, do we want to
> support more than one aliases file?
If they're different types, probably not. But if it's the same type,
it's pretty easy and I don't see why not. This patch applies on top
of the previous one.
Subject: [PATCH] send-email: allow more than one alias file to be used
The aliasfiletype must be the same for all aliasesfiles, though.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
16306f761b34505672a04bff333d6342724756c8
diff --git a/git-send-email.perl b/git-send-email.perl
index d3e1768..5d1e95c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -90,7 +90,7 @@ my ($author) = gitvar_ident('GIT_AUTHOR_
my ($committer) = gitvar_ident('GIT_COMMITTER_IDENT');
my %aliases;
-chomp(my $aliases_file = `git-repo-config sendemail.aliasesfile`);
+chomp(my @alias_files = `git-repo-config --get-all sendemail.aliasesfile`);
chomp(my $aliasfiletype = `git-repo-config sendemail.aliasfiletype`);
my %parse_alias = (
# multiline formats can be supported in the future
@@ -116,10 +116,12 @@ my %parse_alias = (
}}}
);
-if ($aliases_file && defined $parse_alias{$aliasfiletype}) {
- open my $fh, '<', $aliases_file or die "opening $aliases_file: $!\n";
- $parse_alias{$aliasfiletype}->($fh);
- close $fh;
+if (@alias_files && defined $parse_alias{$aliasfiletype}) {
+ foreach my $file (@alias_files) {
+ open my $fh, '<', $file or die "opening $file: $!\n";
+ $parse_alias{$aliasfiletype}->($fh);
+ close $fh;
+ }
}
my $prompting = 0;
--
1.2.4.gb622a
^ permalink raw reply related
* Re: [PATCH] Do not print header in diff-tree --root unless asked to
From: Petr Baudis @ 2006-03-26 1:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu09mt4ij.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Mar 26, 2006 at 01:48:36AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > ... git-diff-tree would always return the sha1 of the commit
> > when --root was passed.
>
> I am not sure why this change is needed.
>
> The output from "git-diff-tree --root e83c51" (the very initial
> "git") and "git-diff-tree 8bc9a0" (the second commit) without
> any other parameters (specifically, there is no '-v') look
> comparable right now, but I suspect this change would break it.
I was confused by the fact that
git-diff-tree --root rev1
gives a different output than
git-diff-tree --root rev1 rev2
Sorry for the noise,
--
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
* Following renames
From: Petr Baudis @ 2006-03-26 1:49 UTC (permalink / raw)
To: git
Hi,
so, now that I've put up with the fuzzy rename autodetection (for
now), I'd like to make cg-log auto-follow renames and I'm wondering
about the best implementation (it seems that I won't do without core
Git cooperation). I think it should be possible to implement in a way
so that it has minimal performance impact and therefore I can have it
turned on by default.
Now I'm using the notorious
git-rev-list listoffiles | git-diff-tree --stdin
pipeline in cg-log, and I'm wondering about the best way to add rename
detection there.
In [1], Linus suggests a non-core solution. Unfortunately, it doesn't
fly - it requires at least two git-ls-tree calls per revision which
would bog things down awfully (to roughly half of the original speed).
But even if git-rev-list reported disappearing files, Cogito would
have to do a lot of complicated bookkeeping in order to properly track
renames in parallel branches - for each 'head' commit at any point of
the history traversal, you need to record a separate set of interesting
files. It would also have to restart git-rev-list at any moment when a
rename happens on any of the head commits. Scales well not.
An obvious solution would be to have git-diff-tree --follow which
updates its interesting path set based on seen renames, and now that
I've written about non-linear history, it's obvious that it's incorrect.
The other obvious way to go is then to add rename detection support to
git-rev-list, and it's less obvious that this is a dead end too - I
didn't inspect the code myself yet, but for now I trust Linus in [2]
(I didn't quite understand the argument, I guess I need to sleep on it).
So, any thoughts about how to approach this? Either git-diff-tree
would have to be taught about the heads bookkeeping, or the git-rev-list
hurdles would have to be overcome, or we might have a
git-rev-rename-filter or something, but that feels quite redundant and
might meet with the same problems as git-rev-list.
== References ==
[1] Oct 21 <Pine.LNX.4.64.0510211814050.10477@g5.osdl.org>
[2] Oct 22 <Pine.LNX.4.64.0510221251330.10477@g5.osdl.org>
--
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: Why would merge fail on a one-line addition?
From: Junio C Hamano @ 2006-03-26 1:32 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20060325222601.GA1500@buici.com>
Marc Singer <elf@buici.com> writes:
> One of the unmerged files leaves this trail.
>
> elf@florence ~...git/linux-2.6 > git-ls-files --unmerged
> 100644 6262d449120cdcde5db1b079806dcc0d9b5e6b7c 1 arch/arm/mach-lh7a40x/irq-lpd7a40x.c
> 100644 dcb4e17b941990eabe8992680c9aa9b67afb6fd4 3 arch/arm/mach-lh7a40x/irq-lpd7a40x.c
> Why would git have a problem with this?
Your change and the change in the other branch are conflicting
and git is helping you notice that.
The index has different #1 and #3 with #2 missing. This means
the common ancestor (#1) had it, you (#2) _removed_ it, while
the other branch (#3) modified it. Should it carry forward the
modification (one line addition) made by the other branch and
then remove the file to match yours, or should it remove it to
match yours and ignore what the other branch did?
If you do not want to have that file in the result, record the
path as such and make a commit. Since there is no #2, your
working tree probably do not have that path, so:
$ git update-index --remove arch/arm/mach-lh7a40x/irq-lpa7a40x.c
to resolve the path, resolve other conflicts if you have any and
then commit the result.
However, this _might_ be a case where your line of development
somewhere between the common ancestor and your tip moved that
file somewhere else in which case you may want to do three-way
merge between 6262d4 blob, your tip and dcb4e1 blob _and_ commit
the result at the path you have. I do not know if that is the
case and even if so I do not know where you have the
corresponding file in your tree, but just as an example if you
have it in arch/arm/mach-foo/irq-lpd7a40x.c, you would:
$ cd arch/arm/mach-foo/
$ common=$(git unpack-file 6262d4)
$ his=$(git unpack-file dcb4e1)
$ merge irq-lpd7a40x.c $common $his
$ rm -f $common $his
And then eyeball the result of the merge, fix it up as
necessary, and then:
$ git update-index --remove arch/arm/mach-lh7a40x/irq-lpa7a40x.c
$ git update-index arch/arm/mach-foo/irq-lpd7a40x.c
before committing.
^ permalink raw reply
* Re: [PATCH] send-email: address expansion for common mailers
From: Junio C Hamano @ 2006-03-26 1:30 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11433354063582-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Two git repo-config keys are required for this
> (as suggested by Ryan Anderson):
>
> sendemail.aliasesfile = <filename of aliases file>
> sendemail.aliasfiletype = (mutt|gnus|pine|mailrc)
>
> I was initially working on auto-detection, but mailrc and mutt formats
> tend to throw each other off (they're alike, but handle multiple
> addresses per-alias differently).
I think specifying the type explicitly is probably not too much
hassle for the end user, so that is fine. Now, do we want to
support more than one aliases file?
^ permalink raw reply
* [PATCH] send-email: Change from Mail::Sendmail to Net::SMTP
From: Eric Wong @ 2006-03-26 1:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson, Eric Wong
In-Reply-To: <20060325235859.GO26071@mythryan2.michonline.com>
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>
---
Notes: Reverted printf => print change from earlier.
git-send-email.perl | 64 ++++++++++++++++++++++++++++++++-------------------
1 files changed, 40 insertions(+), 24 deletions(-)
8d65a0a4121ade9f48f186d0dcf9f41adc62b22c
diff --git a/git-send-email.perl b/git-send-email.perl
index b220d11..25daf16 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;
} 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
* [PATCH] send-email: address expansion for common mailers
From: Eric Wong @ 2006-03-26 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git, Eric Wong
In-Reply-To: <20060325235017.GN26071@mythryan2.michonline.com>
mutt, gnus, pine, mailrc formats should be supported.
Testing and feedback for correctness and completeness of all formats
and support for additional formats would be good.
Nested expansions are also supported.
Two git repo-config keys are required for this
(as suggested by Ryan Anderson):
sendemail.aliasesfile = <filename of aliases file>
sendemail.aliasfiletype = (mutt|gnus|pine|mailrc)
I was initially working on auto-detection, but mailrc and mutt formats
tend to throw each other off (they're alike, but handle multiple
addresses per-alias differently).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
aea3aaf9571ab639c67608f62771e73104842294
diff --git a/git-send-email.perl b/git-send-email.perl
index 7cbf11d..208c119 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -89,6 +89,39 @@ sub gitvar_ident {
my ($author) = gitvar_ident('GIT_AUTHOR_IDENT');
my ($committer) = gitvar_ident('GIT_COMMITTER_IDENT');
+my %aliases;
+chomp(my $aliases_file = `git-repo-config sendemail.aliasesfile`);
+chomp(my $aliasfiletype = `git-repo-config sendemail.aliasfiletype`);
+my %parse_alias = (
+ # multiline formats can be supported in the future
+ mutt => sub { my $fh = shift; while (<$fh>) {
+ if (/^alias\s+(\S+)\s+(.*)$/) {
+ my ($alias, $addr) = ($1, $2);
+ $addr =~ s/#.*$//; # mutt allows # comments
+ # commas delimit multiple addresses
+ $aliases{$alias} = [ split(/\s*,\s*/, $addr) ];
+ }}},
+ mailrc => sub { my $fh = shift; while (<$fh>) {
+ if (/^alias\s+(\S+)\s+(.*)$/) {
+ # spaces delimit multiple addresses
+ $aliases{$1} = [ split(/\s+/, $2) ];
+ }}},
+ pine => sub { my $fh = shift; while (<$fh>) {
+ if (/^(\S+)\s+(.*)$/) {
+ $aliases{$1} = [ split(/\s*,\s*/, $2) ];
+ }}},
+ gnus => sub { my $fh = shift; while (<$fh>) {
+ if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
+ $aliases{$1} = [ $2 ];
+ }}}
+);
+
+if ($aliases_file && defined $parse_alias{$aliasfiletype}) {
+ open my $fh, '<', $aliases_file or die "opening $aliases_file: $!\n";
+ $parse_alias{$aliasfiletype}->($fh);
+ close $fh;
+}
+
my $prompting = 0;
if (!defined $from) {
$from = $author || $committer;
@@ -112,6 +145,19 @@ if (!@to) {
$prompting++;
}
+sub expand_aliases {
+ my @cur = @_;
+ my @last;
+ do {
+ @last = @cur;
+ @cur = map { $aliases{$_} ? @{$aliases{$_}} : $_ } @last;
+ } while (join(',',@cur) ne join(',',@last));
+ return @cur;
+}
+
+@to = expand_aliases(@to);
+@initial_cc = expand_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
* Re: [PATCH 1/4] send-email: Change from Mail::Sendmail to Net::SMTP
From: Junio C Hamano @ 2006-03-26 1:09 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060326005424.GA1773@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> print gettext('Send '),$subject,"\n";
Nak; who said all languages have verb before what the verb acts
upon?
^ permalink raw reply
* Re: [PATCH 1/4] send-email: Change from Mail::Sendmail to Net::SMTP
From: Eric Wong @ 2006-03-26 0:54 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git, Greg KH
In-Reply-To: <20060325235859.GO26071@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> wrote:
> On Sat, Mar 25, 2006 at 02:43:30AM -0800, Eric Wong wrote:
> > 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.
>
> Overall, I like this set of cleanups, just one thing struck me as,
> "why?"
>
> > if ($quiet) {
> > - printf "Sent %s\n", $subject;
> > + print "Sent $subject\n";
>
> This seems to be a pointless change, and actually, might be long-term
> counterproductive.
Force of habit, I think. I originally rewrote that portion but thought
I reverted it back to the way it was. Besides, it's even slightly
faster this way :) It could still be faster(!) if I just printed a list
(like below).
> Assumption: Eventually, we're going to want to internationalize git.
>
> If that is true, we'll eventually do something like this to lines like
> that:
> printf( gettext("Send %s\n"), $subject);
>
> The alternative:
> print gettext("Send $subject\n");
> does not work.
print gettext('Send '),$subject,"\n";
> (The line that xgettext will see is 'Send $subject\n', but when the
> program actually runs, gettext will see the interpolated version, which
> fails.)
>
> Internationalization may still be a ways off, but I think we're reaching
> the point where it might be something we care to think about.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Do not print header in diff-tree --root unless asked to
From: Junio C Hamano @ 2006-03-26 0:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060325232807.9146.12846.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> ... git-diff-tree would always return the sha1 of the commit
> when --root was passed.
I am not sure why this change is needed.
The output from "git-diff-tree --root e83c51" (the very initial
"git") and "git-diff-tree 8bc9a0" (the second commit) without
any other parameters (specifically, there is no '-v') look
comparable right now, but I suspect this change would break it.
^ permalink raw reply
* [PATCH] send-email: lazy-load Email::Valid and make it optional
From: Eric Wong @ 2006-03-26 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <7v8xqyuuvo.fsf@assigned-by-dhcp.cox.net>
It's not installed on enough machines, and is overkill most of
the time. We'll fallback to a very basic regexp just in case,
but nothing like the monster regexp Email::Valid has to offer :)
Small cleanup from Merlyn.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
3f09a822e3871eeae521da80c748602862fc52ce
diff --git a/git-send-email.perl b/git-send-email.perl
index 5e08817..7cbf11d 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; 1 };
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
* Re: Why would merge fail on a one-line addition?
From: Linus Torvalds @ 2006-03-26 0:31 UTC (permalink / raw)
To: Marc Singer; +Cc: Git Mailing List
In-Reply-To: <20060325222601.GA1500@buici.com>
On Sat, 25 Mar 2006, Marc Singer wrote:
> One of the unmerged files leaves this trail.
>
> elf@florence ~...git/linux-2.6 > git-ls-files --unmerged
> 100644 6262d449120cdcde5db1b079806dcc0d9b5e6b7c 1 arch/arm/mach-lh7a40x/irq-lpd7a40x.c
> 100644 dcb4e17b941990eabe8992680c9aa9b67afb6fd4 3 arch/arm/mach-lh7a40x/irq-lpd7a40x.c
>
> elf@florence ~...git/linux-2.6 > git-cat-file blob 6262d449120cdcde5db1b079806dcc0d9b5e6b7c > a
> elf@florence ~...git/linux-2.6 > git-cat-file blob dcb4e17b941990eabe8992680c9aa9b67afb6fd4 > b
> elf@florence ~...git/linux-2.6 > diff a b 21a22
> > #include "common.h"
>
> Why would git have a problem with this?
That whole file was apparently removed in the branch you are merging into
(no stage 2). So what should the merge do? Throw away the one-liner
addition (likely the correct thing) or maybe it should go somewhere else
(ie maybe it wasn't removed outright, but the contents moved into another
file, which would now need the one-line addition).
Linus
^ permalink raw reply
* Re: [PATCH 1/4] send-email: Change from Mail::Sendmail to Net::SMTP
From: Ryan Anderson @ 2006-03-25 23:58 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git, Greg KH
In-Reply-To: <11432834102700-git-send-email-normalperson@yhbt.net>
On Sat, Mar 25, 2006 at 02:43:30AM -0800, Eric Wong wrote:
> 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.
Overall, I like this set of cleanups, just one thing struck me as,
"why?"
> if ($quiet) {
> - printf "Sent %s\n", $subject;
> + print "Sent $subject\n";
This seems to be a pointless change, and actually, might be long-term
counterproductive.
Assumption: Eventually, we're going to want to internationalize git.
If that is true, we'll eventually do something like this to lines like
that:
printf( gettext("Send %s\n"), $subject);
The alternative:
print gettext("Send $subject\n");
does not work.
(The line that xgettext will see is 'Send $subject\n', but when the
program actually runs, gettext will see the interpolated version, which
fails.)
Internationalization may still be a ways off, but I think we're reaching
the point where it might be something we care to think about.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH 4/4] send-email: add support for mutt aliases files
From: Ryan Anderson @ 2006-03-25 23:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7vfyl6uuzt.fsf@assigned-by-dhcp.cox.net>
On Sat, Mar 25, 2006 at 12:31:18PM -0800, Junio C Hamano wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > More email clients/address book formats can easily be supported
> > in the future.
>
> > +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:
> > +
>
> I'd rather avoid proliferation of sendemail.{foo,bar,mutt,pine,...}aliases
> variables. Can we autodetect the alias file format and parse
> the given file accordingly?
Don't bother - instead of lots of variables, just have two:
sendemail.aliasesfile
sendemail.aliasfiletype
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH] Do not print header in diff-tree --root unless asked to
From: Petr Baudis @ 2006-03-25 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Currently cg-log -f is broken (shows sha1 in files list for the initial
commit) since git-diff-tree would always return the sha1 of the commit
when --root was passed. I assume it should do this only when -v was also
passed; I'm certain that I don't want it when processing the output.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
diff-tree.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/diff-tree.c b/diff-tree.c
index f55a35a..8d82b5b 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -107,7 +107,8 @@ static int diff_tree_commit(struct commi
/* Root commit? */
if (show_root_diff && !commit->parents) {
- header = generate_header(sha1, NULL, commit);
+ if (verbose_header)
+ header = generate_header(sha1, NULL, commit);
diff_root_tree(sha1, "");
}
^ permalink raw reply related
* [PATCH]: git-svnimport: if a limit is specified, respect it
From: Anand Kumria @ 2006-03-25 22:43 UTC (permalink / raw)
To: git; +Cc: Anand Kumria
Hi,
git-svnimport will import the same revision over and over again if a
limit (-l <rev>) has been specified. Instead if that revision has already
been processed, exit with an up-to-date message.
Please apply.
Thanks,
Anand
Signed-off-by: Anand Kumria <wildfire@progsoc.org>
---
git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
66e05a5854eb269e3e61fcaa9f53a4b2a45b17d8
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 639aa41..114784f 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -851,7 +851,7 @@ sub commit_all {
$opt_l = $svn->{'maxrev'} if not defined $opt_l or $opt_l > $svn->{'maxrev'};
-if ($svn->{'maxrev'} < $current_rev) {
+if ($opt_l < $current_rev) {
print "Up to date: no new revisions to fetch!\n" if $opt_v;
unlink("$git_dir/SVN2GIT_HEAD");
exit;
--
1.2.4
^ permalink raw reply related
* Why would merge fail on a one-line addition?
From: Marc Singer @ 2006-03-25 22:26 UTC (permalink / raw)
To: Git Mailing List
One of the unmerged files leaves this trail.
elf@florence ~...git/linux-2.6 > git-ls-files --unmerged
100644 6262d449120cdcde5db1b079806dcc0d9b5e6b7c 1 arch/arm/mach-lh7a40x/irq-lpd7a40x.c
100644 dcb4e17b941990eabe8992680c9aa9b67afb6fd4 3 arch/arm/mach-lh7a40x/irq-lpd7a40x.c
elf@florence ~...git/linux-2.6 > git-cat-file blob 6262d449120cdcde5db1b079806dcc0d9b5e6b7c > a
elf@florence ~...git/linux-2.6 > git-cat-file blob dcb4e17b941990eabe8992680c9aa9b67afb6fd4 > b
elf@florence ~...git/linux-2.6 > diff a b 21a22
> #include "common.h"
Why would git have a problem with this?
^ permalink raw reply
* Re: starting completly new repository
From: Petr Baudis @ 2006-03-25 21:49 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0603252148550.14361@alpha.polcom.net>
Hi,
Dear diary, on Sat, Mar 25, 2006 at 10:06:42PM CET, I got a letter
where Grzegorz Kulewski <kangur@polcom.net> said that...
> First sorry if it is anwsered somewhere in the docs, but I am just
> (slowly) learning how to use git and reading the documentation. Any
> pointers to some article or tutorial that anwsers my questions will be
> appreciated.
well, there's Documentation/tutorial.txt, but it doesn't cover your
questions, it looks.
> But it looks like I must first do some commit on the server? But I can not
> make empty commit just to have things started? Or maybe there is some
> other way...
You can of course make an empty commit, but it seems strange that you
would want that - won't the people start working on some initial version
of the project?
> Also I wonder if I can do push over git protocol or I must use real ssh
> account on the server? This is not clear from the docs... At least not for
> me. How should I set up my repo (on my computer) to be able to push
> commits into main repo?
You must use real ssh account on the server. You can limit the account
to be able to do only git pushes/pulls by setting its shell to
git-shell.
> Also what should I set up additionally? How can I easily set author name
> and email for each repo? What is the difference between author and
> commiter and how should I set this up here?
From Cogito's cg-commit documentation:
Each commit has two user identification fields - commit author and
committer. By default, it is recorded that you authored the commit, but
it is considered a good practice to change this to the actual author of
the change if you are merely applying someone else's patch. It is always
recorded that you were the patch committer.
> Is there any documentation about git config file? Can I set author name,
> email and preffered editor in it or must I use environment?
See git-commit-tree(1), the COMMIT INFORMATION section.
One big problem with Git documentation (other than e.g. falling
out-of-date occassionaly) is that information is scattered between
porcelain and plumbing or even between several commands (e.g.
git-whatchanged(1) which doesn't even directly mention where to gather
the full list of available options).
Thankfully, the plumbing documentation is mostly coherent. ;-)
> Is there some irc channel for asking dumb questions as above and having
> them anwsered fast or should I use this mailing list?
#git on Freenode (surprisingly ;)
--
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: starting completly new repository
From: sean @ 2006-03-25 21:45 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0603252148550.14361@alpha.polcom.net>
On Sat, 25 Mar 2006 22:06:42 +0100 (CET)
Grzegorz Kulewski <kangur@polcom.net> wrote:
> (on the server)
> mkdir main
> git-init-db
> touch .git/git-daemon-export-ok
>
> (on my computer)
> git-clone git://host/main main
>
> But it looks like I must first do some commit on the server? But I can not
> make empty commit just to have things started? Or maybe there is some
> other way...
Did you actually start the git-daemon on the server?
> Also I wonder if I can do push over git protocol or I must use real ssh
> account on the server? This is not clear from the docs... At least not for
> me. How should I set up my repo (on my computer) to be able to push
> commits into main repo?
You can't commit over the git protocol, you'll need to use ssh.
No need to do anything to your repo in order to push.
> Also what should I set up additionally? How can I easily set author name
> and email for each repo?
See below.
> What is the difference between author and commiter and how should I
> set this up here?
Just what you might imagine, the person who created the patch and
the person who entered it into the repository respectively.
> Is there any documentation about git config file? Can I set author name,
> email and preffered editor in it or must I use environment?
$ git repo-config user.email "user@email.com"
$ git repo-config user.name "full name"
use the EDITOR environment variable to choose your desired editor.
> Is there some irc channel for asking dumb questions as above and having
> them anwsered fast or should I use this mailing list?
#git on irc.freenode.net
Sean
^ permalink raw reply
* More "git-apply" safety fixes
From: Linus Torvalds @ 2006-03-25 21:28 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This was triggered by me testing the "@@" numbering shorthand by GNU
patch, which not only showed that git-apply thought it meant the number
was duplicated (when it means that the second number is 1), but my tests
showed than when git-apply mis-understood the number, it would then not
raise an alarm about it if the patch ended early.
Now, this doesn't actually _matter_, since with a three-line context, the
only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in
which case git-apply got it right), but the fact that git-apply would also
silently accept truncated patches was a missed opportunity for additional
sanity-checking.
So make git-apply refuse to look at a patch fragment that ends early.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
If you already applied the first hunk, just ignore that part, and apply
the second one that adds the test for oldlines/newlines being zero after
the patch.
Neither of these two changes should matter for a well-formed patch, but
it's definitely the right thing to do.
diff --git a/apply.c b/apply.c
index 2da225a..c50b3a6 100644
--- a/apply.c
+++ b/apply.c
@@ -693,7 +693,7 @@ static int parse_range(const char *line,
line += digits;
len -= digits;
- *p2 = *p1;
+ *p2 = 1;
if (*line == ',') {
digits = parse_num(line+1, p2);
if (!digits)
@@ -901,6 +901,8 @@ static int parse_fragment(char *line, un
break;
}
}
+ if (oldlines || newlines)
+ return -1;
/* If a fragment ends with an incomplete line, we failed to include
* it in the above loop because we hit oldlines == newlines == 0
* before seeing it.
^ permalink raw reply related
* starting completly new repository
From: Grzegorz Kulewski @ 2006-03-25 21:06 UTC (permalink / raw)
To: git
Hi,
First sorry if it is anwsered somewhere in the docs, but I am just
(slowly) learning how to use git and reading the documentation. Any
pointers to some article or tutorial that anwsers my questions will be
appreciated.
What I am trying to do is to construct several repositories for the
following work order:
1. There is some remote repo that is the main repository (call it main).
It lives in some server and geneerally only one or two persons can push
into it. All others can only pull from it.
2. Everybody has his own repo derived from main and she/he can make
patches and send it to everybody else. One person is responsible for
taking the patches and pushing them into main.
I need this set up fast and want to know how to do it. What I tried is
basically:
(on the server)
mkdir main
git-init-db
touch .git/git-daemon-export-ok
(on my computer)
git-clone git://host/main main
But it looks like I must first do some commit on the server? But I can not
make empty commit just to have things started? Or maybe there is some
other way...
Also I wonder if I can do push over git protocol or I must use real ssh
account on the server? This is not clear from the docs... At least not for
me. How should I set up my repo (on my computer) to be able to push
commits into main repo?
Also what should I set up additionally? How can I easily set author name
and email for each repo? What is the difference between author and
commiter and how should I set this up here?
Is there any documentation about git config file? Can I set author name,
email and preffered editor in it or must I use environment?
Is there some irc channel for asking dumb questions as above and having
them anwsered fast or should I use this mailing list?
Thanks in advance,
Grzegorz Kulewski
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Linus Torvalds @ 2006-03-25 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Davide Libenzi
In-Reply-To: <7vslp6uvn1.fsf@assigned-by-dhcp.cox.net>
On Sat, 25 Mar 2006, Junio C Hamano wrote:
>
> This is a replacement for my previous one, which reduces the
> changes to the testsuite.
Btw, your comment about the GNU diff @@-line simplification made me look
at that again.
git-apply used to believe that a simplified line (ie with a single value)
meant "x,x". While it seems that it really means "x,1".
Now, at worst, this would probably mean that some patches would get
rejected (rather than mis-applied), so I think we've just never hit it.
Also, with the default 3-line context I think that it simply _cannot_ be
hit (since the only way that the result or source would have only one line
in the resulting is it was the first line).
But if the "x" shorthand really means "x,1" (and I think you're right -
using "-U 1" I can get that kind of shorthand) then apply.c should be
fixed as follows (actual patch: removal of two characters).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/apply.c b/apply.c
index 2da225a..e80cd15 100644
--- a/apply.c
+++ b/apply.c
@@ -693,7 +693,7 @@ static int parse_range(const char *line,
line += digits;
len -= digits;
- *p2 = *p1;
+ *p2 = 1;
if (*line == ',') {
digits = parse_num(line+1, p2);
if (!digits)
^ permalink raw reply related
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