* Re: Following renames
From: Petr Baudis @ 2006-03-26 10:07 UTC (permalink / raw)
To: Linus Torvalds, Ryan Anderson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603251919170.15714@g5.osdl.org>
Dear diary, on Sun, Mar 26, 2006 at 05:19:50AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Sun, 26 Mar 2006, Petr Baudis wrote:
> >
> > 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).
>
> No it doesn't. It requires one git-ls-tree WHEN SOMETHING IS RENAMED.
>
> In other words, basically never.
Huh? I don't see that now (and caps don't help me see it better). That's
certainly not what is in [1], and I don't see _how_ to detect the
renames in this case, and what would I be actually doing git-ls-tree for
when I've already detected the rename. Based on [1], I'd be doing
git-ls-tree merely to detect that a file _disappeared_ in the first
place, I have to do other stuff to detect the renames themselves.
Dear diary, on Sun, Mar 26, 2006 at 09:35:02AM CEST, I got a letter
where Ryan Anderson <ryan@michonline.com> said that...
> A simple example is the first loop in git-annotate.perl. (Which was
> basically written by Linus, I just translated it from a
> shell/pseudo-code example into Perl)
Thanks for the hint. Unfortunately, this is precisely the thing I want
to avoid, that is essentially reimplementing part of git-rev-list - to
do something good, I would have to do my own toposort and merge by date
between parallel lines. OTOH, I might just construct a large revlist
commandline specifying all the segments I'm interested in and see what
happens when I run that.
Besides, doing it in shell would be pretty ugly job (forcing me to
finally rewrite it in perl is not a bad thing but that'd be a somewhat
larger project since I share various common routines with other cg
tools, etc).
--
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: Following renames
From: Ryan Anderson @ 2006-03-26 7:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0603251919170.15714@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
Linus Torvalds wrote:
> On Sun, 26 Mar 2006, Petr Baudis wrote:
>
>> 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).
>>
>
> No it doesn't. It requires one git-ls-tree WHEN SOMETHING IS RENAMED.
>
> In other words, basically never.
>
A simple example is the first loop in git-annotate.perl. (Which was
basically written by Linus, I just translated it from a
shell/pseudo-code example into Perl)
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH] Add git-explode-packs
From: Junio C Hamano @ 2006-03-26 6:12 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <11432881443149-git-send-email-matlads@dsmagic.com>
Martin Atukunda <matlads@dsmagic.com> writes:
> This script does the opposite of git repack -a -d.
The script seems to do what it claims to, but now why would one
need to use this? In other words what's the situation one would
find this useful?
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-03-26 6:00 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
- git-svn memory usage reduction (Eric Wong)
- documentation updates (Francis Daly, Jon Loeliger)
- fix updating working tree after cvsimport reads from CVS
- fetch exits non-zero when fast-forward check fails.
- improve git-pull's failur case when pulling into the tracking branch.
- commit-tree checks return value from write_sha1_file().
- git-apply understands "@@ -l, +m @@" correctly.
----------------------------------------------------------------
* The 'next' branch, in addition, has these.
These are harmless and useful to be pushed into "master"; I just
have not gotten around to.
- updates around git-clone:
. --use-separate-remote
. --reference <repo>
. fetch,parse-remote,fmt-merge-msg: refs/remotes/* support (Eric Wong)
. sha1_name() understands refs/remotes/$foo/HEAD
- sha1_name safety and core.warnambiguousrefs
- git-merge knows some strategies want to skip trivial merges
------------
I really should do some more stats on this and push it out.
Just haven't got around to do so.
- insanely fast rename detection (Linus and me)
------------
These look very good, but people depend on them, so I'd like to
simmer them in "next" for a couple of days to hear success
stories, or "ah crap I got burned" story ;-).
- tar-tree updates (Rene Scharfe)
- send-email updates (Eric Wong)
------------
Hot off the press. I smell the beginning of a good stuff here.
- truly built-in diff (Linus with Davide)
------------
This is harmless to be pushed into "master" but is staying here
only because nobody expressed urgency.
- ls-{files,tree} --abbrev (Eric Wong)
----------------------------------------------------------------
* The 'pu' branch, in addition, has these.
Since I do not have a good guinea pig case to use this, I
haven't read and understood the code being patched enough to
comment on the change this one introduces; it looks obviously
correct, though.
I'd like an ACK or two from people who works with SVN gateway
before I apply this to "master".
- git-svnimport: if a limit is specified, respect it (Anand Kumria)
------------
This script does what it claims to do, but I do not think of a
useful use case for this. When I have packs with garbage
objects in them (because I rewind my "pu" branch I usually end
up having a handful in my packs), I just run "repack -a -d" and
that is good enough. So I need a bit of convincing to keep
this.
- Add git-explode-packs (Martin Atukunda)
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Davide Libenzi @ 2006-03-26 5:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Morten Welinder, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603251040190.15714@g5.osdl.org>
On Sat, 25 Mar 2006, Linus Torvalds wrote:
> Btw, git-apply does it, and it's actually quite simple: the code to handle
> the "\ No newline" case is literally just this:
>
> /*
> * "plen" is how much of the line we should use for
> * the actual patch data. Normally we just remove the
> * first character on the line, but if the line is
> * followed by "\ No newline", then we also remove the
> * last one (which is the newline, of course).
> */
> plen = len-1;
> if (len < size && patch[len] == '\\')
> plen--;
>
> if we just remove the last '\n' on a line, if the _next_ line starts with
> a '\\' (so the git-apply code actually depends on knowing that the patch
> text is dense, and that it's also padded out so that you can look one byte
> past the end of the diff and it won't be a '\\').
>
> I don't know how well that fits into xpatch (I never looked at the patch
> side, since I already had my own ;), but my point being that handling this
> special case _can_ be very simple if the data structures are just set up
> for it.
Yeah, should be a pretty trivial fix in the xpatch parsing code. Thanks
for remembering me the missing-eol issue, that fell forgotten somewhere in
my todo list :D
- Davide
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Davide Libenzi @ 2006-03-26 4:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Morten Welinder, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603251030340.15714@g5.osdl.org>
On Sat, 25 Mar 2006, Linus Torvalds wrote:
> I don't need "patch", since I wrote my own anyway. It's just called
> "apply" instead of "patch".
Oh, ok. I thought you were calling out GNU patch for the task.
> Doing "apply" is not only much simpler than doing "diff", but I needed my
> own much earlier: it's much more timing-critical for me (applying 200
> patches in one go), and git needed something that could honor renames and
> copies, and the mode bits too.
>
> Besides, I hate how GNU patch bends over backwards in applying crap that
> isn't a proper patch at all (whitespace-corruption, you name it: GNU patch
> will accept it). Also, I made "git-apply" be all-or-nothing: either it
> applies the _whole_ patch (across many different files) or it applies none
> of it. With GNU patch, if you get an error on the fifth file, the four
> first files have been modified already - aarrgghhh..
>
> See "apply.c" for details if you care. It's stupid, but it works (and it
> _only_ handles unified diffs - with the git extensions, of course).
So is xdl_patch(). It handles unified diffs, a simple ignore whitespace
changes, and all (methink) the fuzzy merge features of GNU patch.
Okie then, drop me an email if you find bugs in the libxdiff code, so I
can fix the main library.
- Davide
^ permalink raw reply
* Re: Following renames
From: Jakub Narebski @ 2006-03-26 3:52 UTC (permalink / raw)
To: git
In-Reply-To: <7virq1sywj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> 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).
[...]
> 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.
I think one of the better ideas/suggestions about *recording* filenames was
in the "impure renames / history tracking" thread
http://marc.theaimsgroup.com/?l=git&m=114122175216489&w=2
<Pine.LNX.4.64.0603011343170.13612@sheen.jakma.org>
about adding *auxiliary* (helper) information about renames in commits. I'm
not sure about recording parts of the file that were moved or copied. That
might have been left for runtime detection in the likes of pickaxe.
As it would be helper-only information it would ensure backwards
compatibility (older versions would ignore additional information) and
forward compatibility (newer version would fallback to current runtime
renames tracking/detection).
To be generic, I think that the command to record rename/copy or
copy'n'paste/cut'n'paste would take set of source files (one or more,
unless we want to have an option to mark the file as new supressing any
superficial similarities, in which case it would be zero or more), and set
of destination files (one or more, with files which were in source repeated
it was copy, not repeated if it was rename or cut'n'paste; unless we want
to record deletions also, in which case it would be zero or more files).
Such information can be I guess easily entered by user... if one remembers
to record rename/cut'n'paste/etc. that is. Perhaps if it were a way to easy
add such information later, for example confirming detected
renames/relationships during merge... It would be much more difficult for
user to enter the ranges unassisted.
What worries me is that such information, recorded in "own fields to the GIT
revision messages" (in commits) can be used only if you track the ancestry;
it doesn't help if you have only have two or more revisions and not build
relationship graph between them. But maybe I worry unnecessary...
BTW. following renames is important not only in examining file [contents]
history, in the likes of diff, whatchanged, annotate/blame, pickaxe but
also for merges.
References:
===========
* http://marc.theaimsgroup.com/?l=linux-kernel&m=111314792424707
* http://article.gmane.org/gmane.comp.version-control.git/217
* http://marc.theaimsgroup.com/?l=git&m=114123702826251
* http://marc.theaimsgroup.com/?l=git&m=114315795227271
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Following renames
From: Linus Torvalds @ 2006-03-26 3:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060326014946.GB18185@pasky.or.cz>
On Sun, 26 Mar 2006, Petr Baudis wrote:
>
> 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).
No it doesn't. It requires one git-ls-tree WHEN SOMETHING IS RENAMED.
In other words, basically never.
Linus
^ permalink raw reply
* 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
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