* [PATCH] diff: chapter and part in funcname for tex
From: Giuseppe Bilotta @ 2008-08-02 11:55 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1217658945-29908-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enhances the tex funcname by adding support for
chapter and part sectioning commands. It also matches
the starred version of the sectioning commands.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Resend, with Signed-off-by: line
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index c253015..776bce1 100644
--- a/diff.c
+++ b/diff.c
@@ -1380,7 +1380,7 @@ static struct builtin_funcname_pattern {
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
- { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
+ { "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\?{.*\\)$" },
{ "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
};
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-08-02 12:51 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <20080730214521.GC7008@dpotapov.dyndns.org>
On 30. juli. 2008, at 23.45, Dmitry Potapov wrote:
> On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:
>>
>> My point was that autocrlf penalises Windows users just as much as it
>> does Linux users, so why should it be turned on by default on
>> Windows?
>
> Because it does make sense on Windows (I mentioned some reasons for
> that
> in my previous email), and it does NOT make any sense on Linux unless
> you copy files from Windows.
It doesn't make any more sense on Windows than it does on Linux,
unless the user is careless about CRLFs and the repository will be
shared with Linux users. If you have to work with undisciplined
Windows users but don't actually use Windows yourself, it might _seem_
to make sense, but that is an illusion.
>>> And the main argument for having that in this way is that people
>>> with LF
>>> text files should be unnecessary penalized for Windows being
>>> different.
>>
>> I know, but my point is that I don't like to be unnecessarily
>> penalised any more when I am using Windows than when I'm using Linux
>> or OS X.
>
> It seems you still have not realized that from the very day when you
> started to use Windows, you are penalized for that day-in, day-out.
> Let's take something simple. For instance, the hello-world program:
> cat <<=== > hello.c
> #include <stdio.h>
> int main() {
> printf ("Hello world!\n");
> return 0;
> }
> ===
>
> You can compile it on Linux and Windows (using Microsoft Visual C).
> Now, if you run it on Linux, it will print 13 symbols (exactly
> as many as there are symbols in the printf string) while on Windows
> you will get 14 bytes. It means that printf and as many other C
> function on Windows does conversion and penalize you already!
But I don't use printf to store files. What does printf have to do
with anything?
Btw, I'm not actually a "natural" Windows user; I have a Mac on my
desktop, and I prefer Linux to Windows on my own PCs. I often use
Windows at work, though, and I'm trying to make Git work as well as
possible when I do.
>> I would like the default to be "no conversion", and for
>> conversion to be enabled not based on platform, but as a policy
>> decision on the repositories where it actually matters.
>
> If Microsoft C library did not do any conversion, I suspect we would
> have this CRLF conversion at all!
Surely, but unfortunately, I don't live in happy fairy land.
>> You can have anything you like in _your_ repository, of course, but
>> if
>> you're not publishing it anywhere, who cares what your line endings
>> are? Your line endings only matter when you publish.
>
> You can publish only what you have. So, it must decided before.
Yes! Someone should decide that the repository should only have LFs
in it, then flag it as such so that Git can respect that decision.
>> That's why I
>> want a setting that is propagated: so that when you clone a
>> repository
>> with a LF-only policy, Git knows what to do.
>
> LF-only policy is the only sane policy for any text files. It has
> nothing
> to do with clone.
Gah! So close, but so far. What about a repository which already has
CRLFs in it? You're telling me that it shouldn't have CRLFs in it,
which is almost entirely unhelpful.
>> I think the real penalty is that with autocrlf enabled, Git no longer
>> stores exactly what I committed.
>
> And what is wrong with that? In any case, Git deltifies and compress
> your files. Why does it not bother you? So, what matters here is
> whether you are able to get back exactly what you put or not. That's
> why Git has this safecrlf option! Of course, it is guarantee to get
> exactly the same back only if you have the same autocrlf setting,
> but if you have different autocrlf settings, it means that you want
> *different* representation of text files!
My point is that if I commit two files with different line endings, I
want Git to store them that way. Works on Linux by default, doesn't
work on Windows by default. Deltification and compression are
irrelevant since they don't change the content. autocrlf does.
You only want to normalise text files if you (a) have undisciplined
committers, and (b) need to share the repository between Windows and
Unix. Right now, the default configuration of Git assumes that all
Windows users are undisciplined, and that they will always be sharing
repositories with Unix users.
>>> Of course, those who are very careful and have good editors can set
>>> autocrlf=false even on Windows...
>>
>> Right, or who know that the repository they're using will only be
>> shared with other Windows users.
>
> WRONG! Using storing CRLF in text files is a completely idiotic idea.
> Those who do so asked for troubles, so they should not complain!
But some text files need CRLFs, the autocrlf mechanism even caters for
them. And it's not like the extra CR actually hurts anything; I use
Git on Windows with "autocrlf=false", and I've yet to see any problems
with it. The reason I've changed from the default "autocrlf=true" is
that I've seen plenty of problems with that.
>> Internally, Git doesn't really care, does it?
>
> It DOES!!! Such things like merges and diffs and many other every day
> commands do care about end-of-lines and the ONLY end-of-line they
> recognize is '\n'. In fact, there are more than 400 places in Git
> where
> '\n' is used. Of course, not all of them may be qualified as internals
> but many of them do.
Buh? That's crazy talk. The only time CRLFs cause trouble with git
is when autocrlf is enabled. Try this:
git init
echo -n "testing\r\ntesting 2\r\n" > testing
git add testing
git commit
git config --bool --add core.autocrlf true
touch testing
git diff
File with CRLF in the repository, file with CRLF in the working
directory, so where does the difference come from? The same thing
happens with "autocrlf=input", and the problem is obviously a lot
bigger when you're trying to merge.
Now I've shown you when autocrlf is a problem, you show me a case
where CRLFs cause trouble with autocrlf=false.
> So, as long as Git internally consider only LF as the end-of-line.
Bah. To the extent it "cares", Git just sees CR as an extra white
space character before the end-of-line LF, and you know it.
>> Heh. Where I work, we hacked CVS for Windows to get away from that
>> behaviour :)
>
> Maybe, you used Cygwin version of CVS, which had LF, but those Windows
> versions of CVS I used produced CRLF on Windows.
No, we just compiled our own, precisely because we didn't want CVS to
mangle our data, even on Windows. The CVS repositories are used by
Linux and Windows clients, and some developers had their working
directories on cross-platform network shares, so eol conversion just
caused unnecessary problems.
>> Well, what I want is to be able to say "it is necessary to do eol
>> conversion in this repository",
>
> You always can do that in _your_ repository:
> git config core.autocrlf ...
I can, except that (a) any CRLFs already in the repository will cause
trouble, and (b) everyone who clones from me has to make the same
setting manually, or they won't follow the same convention.
>> allowing the default to be "don't do
>> eol conversion" on Windows, too. For a setting like that to be
>> useful, it has to be propagated when the repository is cloned.
>
> Why? Other people may have other preferences.
Yes. Other people may have other preferences which will lead them to
push CRLFs to my repository. That is why the setting should be
propagated.
>> I want it to be versioned because you might want to change it without
>> messing with the content that's already in the repository. This is
>> actually my main motivation, since I have lots of CRLF-infused CVS
>> history to deal with.
>
> Well, you can try to use .gitattributes, but I believe it would be far
> more reasonable to clean this mess with line-ending than finding a
> way to continue insanity with different ending in different text
> files.
But I'd rather not change the historical data in every repository. So
yes, I think it's a good idea to clean up the line endings, but I
would like to do it in a way that allows me to check out an old
version with mixed line endings while still ensuring that newly
committed files are normalised.
>> It should apply on Linux as well as Windows because there is always
>> the chance that a user will manage to commit a CRLF on Linux (a
>> colleague of mine once complained that CVS on Linux doesn't do eol
>> conversion; he edited files on Windows, but checked them in on
>> Linux).
>
> For those who need it, Git provides autocrlf=input. But the question
> here is what should be default. I don't think that those who copies
> files directly from Windows to Linux are majority. OTOH, I don't
> mind autocrlf=input as default. If it can be turned off, it is fine
> with me :)
Yeah, if autocrlf is set, it probably makes sense to use it, i.e.
anyone who doesn't want line ending conversion at all can set
"autocrlf=false".
>> It would probably be okay to have a setting that turns all
>> conversion off, but wouldn't that be kind of rude?
>
> How so?
You're explicitly saying "I don't care if I commit CRLFs into a
repository that requests only LFs". So you're probably only saying it
because you know you won't commit CRLFs anyway, but since the cost is
so low, why not make sure?
--
Eyvind Bernhardsen
^ permalink raw reply
* [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Jan Nieuwenhuizen @ 2008-08-02 13:42 UTC (permalink / raw)
To: git
Some projects write ChangeLog entries and use those for svn
commit messages. Converting such a repository makes for
a most uninteresting git log --pretty=oneline output.
482cfc6... 2008-08-01 Kohei Yoshida <kyoshida@novell.com>
90c16d7... 2008-08-01 Fong Lin <pflin@novell.com> * patches/dev300/cws-npow
505fc23... 2008-08-01 Kohei Yoshida <kyoshida@novell.com>
4729379... 2008-08-01 Kohei Yoshida <kyoshida@novell.com>
9e34b85... 2008-07-31 Kohei Yoshida <kyoshida@novell.com>
ee1855a... 2008-07-31 Jan Nieuwenhuizen <janneke@gnu.org>
518b921... 2008-07-31 Miklos Vajna <vmiklos@frugalware.org>
The --cut-changelog-bits fixes this
44e7784... patches/dev300/apply: added upstream issue numbers to some of my p
1a19026... patches/dev300/cws-npower11.diff: Add vba events stuff.
7422531... patches/test/calc-external-defined-names.diff: more progress; make
66c5975... scratch/sc-xlsutil/src/formula.py:
307fa53... patches/dev300/chart-subtitle-xls-export.diff: preserve the subtitl
0d127af... patches/dev300/layout-simple-dialogs-toolkit.diff: Remove duplicate
843d41e... patches/dev300/apply: Remove gcc401-stlport45-include.diff from Fru
partly. I tried removing the file name bits too, but that makeslog
entries that touch multiple files almost useless.
Signed-off-by: Jan Nieuwenhuizen <Jan Nieuwenhuizen janneke@gnu.org>
---
git-svn.perl | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..651739a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format);
+ $_git_format, $_cut_changelog_bits);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -109,9 +109,11 @@ my %cmd = (
fetch => [ \&cmd_fetch, "Download new revisions from SVN",
{ 'revision|r=s' => \$_revision,
'fetch-all|all' => \$_fetch_all,
+ 'cut-changelog-bits' => \$_cut_changelog_bits,
%fc_opts } ],
clone => [ \&cmd_clone, "Initialize and fetch revisions",
{ 'revision|r=s' => \$_revision,
+ 'cut-changelog-bits' => \$_cut_changelog_bits,
%fc_opts, %init_opts } ],
init => [ \&cmd_init, "Initialize a repo for tracking" .
" (requires URL argument)",
@@ -2463,6 +2465,13 @@ sub make_log_entry {
close $un or croak $!;
$log_entry{date} = parse_svn_date($log_entry{date});
+ if (defined $_cut_changelog_bits) {
+ $log_entry{log} =~ s/(^|\n)\s*((\n|\s)*(199[0-9]|
20[0-1][0-9])(-[0-9]{2}){2}\s+.*<.*>\s*\n\s+)?/$1/g;
+ $log_entry{log} =~ s/(^|\n)\* /\n$1/g;
+ $log_entry{log} =~ s/^[\n\s]*//;
+ $log_entry{log} =~ s/\n\s*/ /g if length ($log_entry{log}) < 81;
+ $log_entry{log} .= "\n";
+ }
$log_entry{log} .= "\n";
my $author = $log_entry{author} = check_author($log_entry{author});
my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
--
1.6.0.rc0.44.g67270
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply related
* [PATCH not ready]: allow cvsimport to use compression when talking to remote cvs server
From: Arkadiusz Miskiewicz @ 2008-08-02 14:05 UTC (permalink / raw)
To: git
This patch adds ability to git cvsimport use compression
when talking to remote cvs pserver (in normal cvs client using compression
makes things a lot faster so it should help here, too).
Unfortunately it doesn't work due to: new IO::Uncompress::RawInflate()
hanging at constructor. No idea why constructor wants to do read()
over a socket. Maybe whole IO::Compress stuff isn't ready to work over
sockets (that's the question to perl gurus).
Fell free to make it working/improve it. I have no idea how to make it work
at this moment.
--- git-cvsimport.org 2008-08-02 12:00:25.342934972 +0200
+++ git-cvsimport 2008-08-02 16:01:33.588363079 +0200
@@ -27,6 +27,15 @@
use POSIX qw(strftime dup2 ENOENT);
use IPC::Open2;
+my $compress_support = 1;
+eval "use IO::Compress::RawDeflate; use IO::Uncompress::RawInflate";
+$compress_support = 0 if ($@);
+if ($compress_support) {
+ use IO::Compress::RawDeflate;
+ use IO::Uncompress::RawInflate;
+}
+
+
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
@@ -312,7 +321,9 @@
my @cvs = ($cvs, 'server');
my ($local, $user, $host);
$local = $repo =~ s/:local://;
- if (!$local) {
+ if ($local) {
+ $compress_support = 0;
+ } else {
$repo =~ s/:ext://;
$local = !($repo =~ s/^(?:([^\@:]+)\@)?([^:]+)://);
($user, $host) = ($1, $2);
@@ -356,6 +367,12 @@
die "validReply: $res\n" if $res ne "ok";
$self->{'socketo'}->write("UseUnchanged\n") if $rep =~ /\bUseUnchanged\b/;
+ if ($compress_support and $rep =~ /\bGzip-stream\b/) {
+ my $level = 3; # make it cmd line option
+ $self->{'socketo'}->write("Gzip-stream $level\n");
+ $self->{'socketo'} = new IO::Compress::RawDeflate $self->{'socketo'},
Level => $level or die("Setting up gzip compression failed:
$IO::Compress::RawDeflate::RawDeflateError\n");
+ $self->{'socketi'} = new IO::Uncompress::RawInflate $self->{'socketi'},
Transparent => 0 or die("Setting up gzip uncompression failed:
$IO::Uncompress::RawInflate::RawInflateError\n");
+ }
$self->{'repo'} = $repo;
}
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [PATCH] diff: add ruby funcname pattern
From: Lee Marlow @ 2008-08-02 15:37 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Kevin Ballard, Junio C Hamano, git
In-Reply-To: <C871A30D-F2AF-4385-ABD4-C57F474D7F01@sb.org>
On Fri, Aug 1, 2008 at 11:47 PM, Kevin Ballard <kevin@sb.org> wrote:
> On Aug 1, 2008, at 10:41 PM, Giuseppe Bilotta wrote:
>
>> On Sat, Aug 2, 2008 at 2:31 AM, Kevin Ballard <kevin@sb.org> wrote:
>
> I think it's far simpler to stick with class/module/def.
>
I agree with Kevin.
It's simpler and I'm not sure what value it would bring to show
anonymous code blocks. The funcname is just to provide some
additional context around the diff hunk, so you know where you are.
What would be shown for an anonymous code block or proc in the diff?
The module/class/method seems to provide the most useful context.
-Lee
^ permalink raw reply
* [PATCH] gitweb: ref markers link to named shortlogs
From: Giuseppe Bilotta @ 2008-08-02 15:39 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
This patch turns ref markers for tags and heads into links to
shortlog/refname. Appropriate changes are made in the CSS to prevent ref
markers to be annoyingly blue and underlined.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.css | 5 +++++
gitweb/gitweb.perl | 5 ++++-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index aa0eeca..2b43eea 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -481,6 +481,11 @@ span.refs span {
border-color: #ffccff #ff00ee #ff00ee #ffccff;
}
+span.refs span a {
+ text-decoration: none;
+ color: inherit;
+}
+
span.refs span.ref {
background-color: #aaaaff;
border-color: #ccccff #0033cc #0033cc #ccccff;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..7f391fa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1093,6 +1093,7 @@ sub format_log_line_html {
sub format_ref_marker {
my ($refs, $id) = @_;
my $markers = '';
+ my $htmltext;
if (defined $refs->{$id}) {
foreach my $ref (@{$refs->{$id}}) {
@@ -1101,13 +1102,15 @@ sub format_ref_marker {
if ($ref =~ m!^(.*?)s?/(.*)$!) {
$type = $1;
$name = $2;
+ $htmltext = $cgi->a({-href => href(action=>"shortlog", hash=>$name)}, $name);
} else {
$type = "ref";
$name = $ref;
+ $htmltext = esc_html($name);
}
$markers .= " <span class=\"$type\" title=\"$ref\">" .
- esc_html($name) . "</span>";
+ $htmltext . "</span>";
}
}
--
1.5.6.3
^ permalink raw reply related
* git svn and the post-receive hook
From: Pascal Obry @ 2008-08-02 16:05 UTC (permalink / raw)
To: git list
At the moment it seems to me that the post-receive hook is not called
when tracking a remove Subversion repository.
I think it would be nice to call the post-receive hook at the end of:
$ git svn rebase
Why I need this?
I'd like to check for example that if a file has been added to the
remote Subversion repository then it is properly added into a MANIFEST
file. I'd also like to check some style rules. This would help to detect
some problems when one has no way to add hooks on the Subversion repository.
I have zero experience with Perl so I do not feel like hacking this myself.
What do you think?
Is this already possible (I may have missed something)?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-02 16:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andrew Morton, Theodore Tso, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0808021321500.9611@pacific.mpi-cbg.de.mpi-cbg.de>
On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>
> Ah, there lies the rub (you forgot that the original complaint was about
> a comma, and pretty=email does not handle those):
Indeed.
I wonder where that is_rfc2047_special() function came from. The list of
"special" characters is totally bogus.
The real RFC has comma, but it has a lot of other characters too:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" /
"<" / "> / "/" / "[" / "]" / "?" / "." / "="
because basically the rfc2047 encoding has to be a superset of the 822
(and later 2822) encodings.
Linus
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-02 16:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Andrew Morton, Theodore Tso, git
In-Reply-To: <alpine.LFD.1.10.0808020916370.3318@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>>
>> Ah, there lies the rub (you forgot that the original complaint was about
>> a comma, and pretty=email does not handle those):
>
> Indeed.
>
> I wonder where that is_rfc2047_special() function came from.
It came from the earlier patch from Dscho I rejected yesterday ;-)
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-02 16:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Andrew Morton, Theodore Tso, git
In-Reply-To: <alpine.LFD.1.10.0808020916370.3318@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>>
>> Ah, there lies the rub (you forgot that the original complaint was about
>> a comma, and pretty=email does not handle those):
>
> Indeed.
>
> I wonder where that is_rfc2047_special() function came from. The list of
> "special" characters is totally bogus.
This function is about quoting inside dq pair, so the function does not
look at the set you listed. It is about quoting non-ascii chars using the
?charset?Q? or ?charset?B? notation.
If we want to use double quotes that should be done elsewhere, not in that
function.
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-02 16:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Andrew Morton, Theodore Tso, git
In-Reply-To: <7vabfvpdyk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>>>
>>> Ah, there lies the rub (you forgot that the original complaint was about
>>> a comma, and pretty=email does not handle those):
>>
>> Indeed.
>>
>> I wonder where that is_rfc2047_special() function came from. The list of
>> "special" characters is totally bogus.
>
> This function is about quoting inside dq pair, so the function does not
s/is about/is NOT about/;
Sorry, I should grab coffee before continuing.
> look at the set you listed. It is about quoting non-ascii chars using the
> ?charset?Q? or ?charset?B? notation.
>
> If we want to use double quotes that should be done elsewhere, not in that
> function.
^ permalink raw reply
* Re: email address handling
From: Johannes Schindelin @ 2008-08-02 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andrew Morton, Theodore Tso, git
In-Reply-To: <7vej57pe5q.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 2 Aug 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > I wonder where that is_rfc2047_special() function came from.
It comes straight from cdd406e(CMIT_FMT_EMAIL: Q-encode Subject: and
display-name part of From: fields.).
Ciao,
Dscho
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-02 17:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andrew Morton, Theodore Tso, git
In-Reply-To: <alpine.DEB.1.00.0808021857350.9611@pacific.mpi-cbg.de.mpi-cbg.de>
On Sat, 2 Aug 2008, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 2 Aug 2008, Junio C Hamano wrote:
>
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > > I wonder where that is_rfc2047_special() function came from.
>
> It comes straight from cdd406e(CMIT_FMT_EMAIL: Q-encode Subject: and
> display-name part of From: fields.).
That's not what I meant.
I meant "what drugs induced somebody to write that function and give it
that name, since it clearly has never seen rfc2047, and has nothing to do
with it".
In other words, it sure as hell didn't come from the rfc2047 in this
universe, so it must have come from some exciting alternate alien universe
with different laws of nature and internet.
Or maybe there's just another rfc2047 that I've not heard of.
Linus
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Petr Baudis @ 2008-08-02 17:27 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1217684549.8296.10.camel@heerbeest>
Hi!
On Sat, Aug 02, 2008 at 03:42:29PM +0200, Jan Nieuwenhuizen wrote:
> Signed-off-by: Jan Nieuwenhuizen <Jan Nieuwenhuizen janneke@gnu.org>
Just your email should be within the <> brackets.
> ---
> git-svn.perl | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
You forgot to document your option. (And possibly write a testcase.)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] hash-object --no-filters
From: Junio C Hamano @ 2008-08-02 17:28 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <20080801220932.GK7008@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> The --no-filters option makes git hash-object to work as there were no
> input filters. This option is useful for importers such as git-svn to
> put new version of files as is even if autocrlf is set.
I think this is going in the right direction, but I have to wonder a few
things.
First, on hash-object.
(1) "hash-object --stdin" always hashes literally. We may want to be
able to say "The contents is this but pretend it came from this path
and apply the usual input rules", perhaps with "--path=" option;
(2) "hash-object temporaryfile" may want to honor the same "--path"
option;
(3) "hash-object --stdin-paths" may want to get pair of paths (i.e. two
lines per entry) to do the same.
If we want to do the above, the existing low-level interface needs to be
adjusted.
index_pipe() and index_fd() can learn to take an additional string
parameter for attribute lookup to implement (1) and (2) above. Perhaps
the string can be NULL to signal --no-filter behaviour, in which case the
HASH_OBJECT_LITERALLY change may not be necessary for this codepath.
index_path() is a healper for add_to_index() which is used for normal
addition of working tree entities, and I do not see an immediate need to
teach it about this "use this different path for attribute lookup" at
least for now.
By the way, why do we have index_pipe() and index_fd() to begin with? Is
it because users of index_pipe() do not know what the path it is hashing
and also the fd being a pipe we cannot mmap it?
If these two are the only reasons, then I wonder if we can:
- accept NULL as path and stat parameters for callers without a filename
(which automatically implies we are doing a regular blob and we hash
literally); and
- first try to mmap(), and if it fails fall back to the "read once into
strbuf" codepath to solve mmap-vs-pipe issue.
I am not sure if such a unification of these two functions is useful,
though.
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Junio C Hamano @ 2008-08-02 17:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jan Nieuwenhuizen, git
In-Reply-To: <20080802172742.GT32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hi!
>
> On Sat, Aug 02, 2008 at 03:42:29PM +0200, Jan Nieuwenhuizen wrote:
>> Signed-off-by: Jan Nieuwenhuizen <Jan Nieuwenhuizen janneke@gnu.org>
>
> Just your email should be within the <> brackets.
>
>> ---
>> git-svn.perl | 11 ++++++++++-
>> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> You forgot to document your option. (And possibly write a testcase.)
I am not sure if this is generic enough to be in git-svn.perl itself, or
perhaps there should be a hook make_log_entry() would call in the form of
some Perl scriptlet given by the user to munge $log_entry{log}, which
would be very specific to each project.
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-02 17:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Andrew Morton, Theodore Tso, git
In-Reply-To: <alpine.LFD.1.10.0808020916370.3318@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>>
>> Ah, there lies the rub (you forgot that the original complaint was about
>> a comma, and pretty=email does not handle those):
>
> Indeed.
>
> I wonder where that is_rfc2047_special() function came from. The list of
> "special" characters is totally bogus.
>
> The real RFC has comma, but it has a lot of other characters too:
>
> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" /
> "<" / "> / "/" / "[" / "]" / "?" / "." / "="
>
> because basically the rfc2047 encoding has to be a superset of the 822
> (and later 2822) encodings.
Hmm, you're right. This has to be trickier than I originally thought it
would be ... ;-)
^ permalink raw reply
* Re: [PATCH] diff: chapter and part in funcname for tex
From: Junio C Hamano @ 2008-08-02 17:59 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1217678145-2630-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> This patch enhances the tex funcname by adding support for
> chapter and part sectioning commands. It also matches
> the starred version of the sectioning commands.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>
> ---
>
> Resend, with Signed-off-by: line
>
> diff.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index c253015..776bce1 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1380,7 +1380,7 @@ static struct builtin_funcname_pattern {
> "^[ ]*\\(\\([ ]*"
> "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
> "[ ]*([^;]*\\)$" },
> - { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
> + { "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\?{.*\\)$" },
Ok on idea, but NAK on implementation.
"A\?" to mean 0 or one "A" in BRE is GNU extention and we try to avoid it.
"A\{0,1\}" is equivalent and we already use the bound notation in "java"
section, so perhaps this is an Ok replacement?
{ "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$" },
^ permalink raw reply
* Re: git svn and the post-receive hook
From: Miklos Vajna @ 2008-08-02 18:03 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <489485BC.1020607@obry.net>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Sat, Aug 02, 2008 at 06:05:16PM +0200, Pascal Obry <pascal@obry.net> wrote:
> At the moment it seems to me that the post-receive hook is not called when
> tracking a remove Subversion repository.
Sure. From the "post-receive" hook documentation:
"This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git-push' is done on a local repository."
And git svn will never invoke git receive-pack.
> I think it would be nice to call the post-receive hook at the end of:
>
> $ git svn rebase
What about a post-rebase hook, like there is a post-merge one?
> I have zero experience with Perl so I do not feel like hacking this myself.
git rebase is shell. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Junio C Hamano @ 2008-08-02 18:12 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <1217510434-94979-1-git-send-email-pdebie@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> Or was there a specific reason not to allow this?
The --name-only option to the command was added in 1.5.3 cycle, but the
original focus was only to support describe. I do not see any fundamental
reason to disallow it --- we could even say this is a bug.
I've applied the "split single line processing to a separate function" and
then this patch to 'maint' as a bugfix.
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Jan Nieuwenhuizen @ 2008-08-02 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vfxpnnwt5.fsf@gitster.siamese.dyndns.org>
On za, 2008-08-02 at 10:36 -0700, Junio C Hamano wrote:
> > You forgot to document your option. (And possibly write a testcase.)
>
> I am not sure if this is generic enough to be in git-svn.perl itself, or
> perhaps there should be a hook make_log_entry() would call in the form of
> some Perl scriptlet given by the user to munge $log_entry{log}, which
> would be very specific to each project.
If you're not sure, please make up your mind. I agree it's quite a hack
but now it's in the archives for others to find. Doing this in a single
regexp is a bit tricky and asking a user to write a perl snippet is even
worse, imho. Especially if would turn out that stripping changelog bits
is the only thing that the hook is getting used for, in the end. I have
gotten more careful to provide generic solutions to specific problems in
anticipation of possible future desires.
I could imagine that leaving git-svn alone and adding a hook to git-log
would be more useful, though.
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Jan Nieuwenhuizen @ 2008-08-02 18:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080802172742.GT32184@machine.or.cz>
On za, 2008-08-02 at 19:27 +0200, Petr Baudis wrote:
> On Sat, Aug 02, 2008 at 03:42:29PM +0200, Jan Nieuwenhuizen wrote:
> > Signed-off-by: Jan Nieuwenhuizen <Jan Nieuwenhuizen janneke@gnu.org>
>
> Just your email should be within the <> brackets.
Oops :-) I have
EMAIL='Jan Nieuwenhuizen <janneke@gnu.org>'
so I should probably use GIT_EMAIL='janneke@gnu.org' or something. I'll
have a look.
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* Re: git svn and the post-receive hook
From: Junio C Hamano @ 2008-08-02 18:22 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <489485BC.1020607@obry.net>
Pascal Obry <pascal@obry.net> writes:
> At the moment it seems to me that the post-receive hook is not called
> when tracking a remove Subversion repository.
>
> I think it would be nice to call the post-receive hook at the end of:
>
> $ git svn rebase
>
> Why I need this?
>
> I'd like to check ...
Wait a minute.
Isn't "git svn rebase" an operation that you do on your local repository,
slurping the update from the other end and then replaying your change on
top of it? If so, I think it falls into the same category as "post-fetch"
hook which would run after you run fetch, if such a thing existed. See:
http://thread.gmane.org/gmane.comp.version-control.git/79306/focus=79321
for the reason why we usually do not add such a hook on the local end.
^ permalink raw reply
* Re: git svn and the post-receive hook
From: Junio C Hamano @ 2008-08-02 18:43 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <489485BC.1020607@obry.net>
Pascal Obry <pascal@obry.net> writes:
> I'd like to check for example that if a file has been added to the
> remote Subversion repository then it is properly added into a MANIFEST
> file. I'd also like to check some style rules. This would help to
> detect some problems when one has no way to add hooks on the
> Subversion repository.
Are you saying that there may be breakages that is made at the Subversion
side, and you would want to catch it?
What would you do _after_ finding out that somebody screwed up and you
have a borked history on the Subversion side already?
I do not think this belongs to "git svn rebase" (let alone "git rebase",
no way --- you won't rewrite nor reject the upstream even if you find
problems with it).
I understand that you would at least want to notice the damange to the
history that happened at the remote end, and I agree it would make sense
to do something like:
$ git command-that-updates-the-remote-tracking-branch git-svn
$ check-history git-svn@{1}..git-svn
The "command-that-updates" could be "svn fetch" or just a simple "fetch".
But the "check-history" script will be very specific to your project, and
I do not think it makes sense to make it a hook to the "command-that-updates".
^ permalink raw reply
* Re: [PATCH 1/2] clone: Add an option to set up a mirror
From: Junio C Hamano @ 2008-08-02 18:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0808011600170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The command line
>
> $ git clone --mirror $URL
>
> is now a short-hand for
>
> $ git clone --bare $URL
> $ (cd $(basename $URL) && git remote add --mirror origin $URL)
I think this would be a useful behaviour and I am very tempted to violate
the general policy of not taking any new options nor features after -rc1.
I however notice that there are differences bewteen the above sequence and
what your code actually does:
- The "remote add --mirror" sequence tells it to mirror everything, but
the patch still mirrors only heads;
- You are not setting up "remote.*.mirror = yes" in the configuration;
^ 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