* [PATCH] gitview: import only one of gtksourceview and gtksourceview2
From: Anton Gyllenberg @ 2007-11-19 10:37 UTC (permalink / raw)
To: git, gitster; +Cc: Anton Gyllenberg
Importing both gtksourceview and gtksourceview2 will make python segfault
on my system (ubuntu 7.10). Change so that gtksourceview is only imported
if importing gtksourceview2 fails. This should be safe as gtksourceview
is only used if gtksourceview2 is not available.
Signed-off-by: Anton Gyllenberg <anton@iki.fi>
---
contrib/gitview/gitview | 17 +++++++----------
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 449ee69..4c99dfb 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -27,20 +27,17 @@ import math
import string
import fcntl
+have_gtksourceview2 = False
+have_gtksourceview = False
try:
import gtksourceview2
have_gtksourceview2 = True
except ImportError:
- have_gtksourceview2 = False
-
-try:
- import gtksourceview
- have_gtksourceview = True
-except ImportError:
- have_gtksourceview = False
-
-if not have_gtksourceview2 and not have_gtksourceview:
- print "Running without gtksourceview2 or gtksourceview module"
+ try:
+ import gtksourceview
+ have_gtksourceview = True
+ except ImportError:
+ print "Running without gtksourceview2 or gtksourceview module"
re_ident = re.compile('(author|committer) (?P<ident>.*) (?P<epoch>\d+) (?P<tz>[+-]\d{4})')
--
1.5.3.2
^ permalink raw reply related
* [PATCH] Don't print an empty Cc header in SMTP mode when there's no cc recipient defined
From: Ask Bjørn Hansen @ 2007-11-19 10:48 UTC (permalink / raw)
To: git; +Cc: Ask Bjørn Hansen
In-Reply-To: <7voddqodhs.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
---
There's some duplicate code between "what we do for sendmail"
and "what we do for SMTP" paths that should be fixed - this doesn't
do that, it only makes the SMTP path skip empty Cc lines...
git-send-email.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index fd0a4ad..65620ab 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -651,7 +651,11 @@ X-Mailer: git-send-email $gitversion
} else {
print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
}
- print "From: $sanitized_sender\nSubject: $subject\nCc: $cc\nTo: $to\n\n";
+ print "From: $sanitized_sender\n"
+ . "Subject: $subject\n"
+ . ($cc ? "Cc: $cc\n" : "")
+ . "To: $to\n"
+ . "\n";
if ($smtp) {
print "Result: ", $smtp->code, ' ',
($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
--
1.5.3.5.561.g140d
^ permalink raw reply related
* [PATCH] Don't add To: recipients to the Cc: header
From: Ask Bjørn Hansen @ 2007-11-19 11:00 UTC (permalink / raw)
To: git; +Cc: Ask Bjørn Hansen
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
---
git-send-email.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 65620ab..530b456 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -557,8 +557,11 @@ sub sanitize_address
sub send_message
{
my @recipients = unique_email_list(@to);
- @cc = (map { sanitize_address($_) } @cc);
+ @cc = (grep { my $cc = extract_valid_address($_);
+ not grep { $cc eq $_ } @recipients
+ }
+ map { sanitize_address($_) }
+ @cc);
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc,@bcclist);
@recipients = (map { extract_valid_address($_) } @recipients);
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [BUG] encoding problem with format-patch + send-email
From: Brian Swetland @ 2007-11-19 10:58 UTC (permalink / raw)
To: Uwe Kleine-König, Jeff King, Junio C Hamano, git
In-Reply-To: <20071119104950.GB8645@informatik.uni-freiburg.de>
[Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>]
> Hello Jeff
>
> Brian sent another mail to the linux-arm-kernel mailing list, now
> spotting:
>
> Content-Type: text/plain; charset=UTF-8
>
> but no Content-Transfer-Encoding:. This yield a 7bit mail with 8bit
> characters.
I actually tacked the Content-Type on by hand on that one.
I haven't had a chance to try the updated send-email, so it may well
do the right thing.
Brian
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Ask Bjørn Hansen @ 2007-11-19 11:05 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1195470026-7389-1-git-send-email-ask@develooper.com>
On Nov 19, 2007, at 3:00 AM, Ask Bjørn Hansen wrote:
Whoops. I thought I stopped the mailing of the first patch. It was
adding whitespace to the end of one of the lines. Sorry about the
duplication!
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Jakub Narebski @ 2007-11-19 11:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5oeocnr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> What's left is a new switch "--current". Less code, easy
>> to explain.
>
> But won't that force the "current" people always type that from
> the command line, as your previous point was that your earlier
> patch to say "remote.$there.push = HEAD" does not work that way?
> If that configuration works as expected, then I'd 100% agree
> that we would not need push.defaultRefs. Either you do not have
> "push" at all if your preference is --matching, or you do have
> "push = HEAD" if your preference is --current. But if it
> doesn't (which was what I gathered from your earlier response),
> having a configuration would help them, wouldn't it?
Brief recap, to check if I understand things correctly:
1. If you use "matching" more often, then it should be enough to provide
remote.<remotename>.push with refspec or wildcard refspec. "git push"
would push matching. If one wants to push only current branch, one
would use "git push --current" or "git push <remotename> HEAD".
Question: what to do if there is no remote.<remotename>.push? Assume
1-1 matching?
2. If you use "current" more often, then it should be anough (after
correcting git; although it was written that it is quite a bit of work)
to provide "remote.<remotename>.push = HEAD", or
"push.defaultRefs = current" if one wants to set this up for all
remotes, or perhaps "remote.*.push = HEAD". "git push" would push
current. If one wants to push matching, one would use "git push
--matching"... although for matching one needs remote configured...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Catalin Marinas @ 2007-11-19 11:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711190005.49990.jnareb@gmail.com>
On 18/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> I use Stacked GIT 0.13 with git 1.5.3.5 (and Python 2.4.3).
> StGIT does recognize old StGIT branches (and converts them),
> but "stg branch -l" list only one branch. I guess that is
> cause by the fact that all the rest of branches are packed.
Have you tried the latest StGIT snapshot. We added support for this
and it will be available in 0.14 (to be released pretty soon).
> Another StGIT question: how to check if given branch is controlled
> by StGIT (needed for my bash prompt)?
'stg branch -l' lists the branches and marks those controlled by
StGIT. For a simple test, just use a command which would fail on
non-stgit branches (stg id base). Yet another way is to check for the
presence of '.git/patches/<branch>'.
--
Catalin
^ permalink raw reply
* [user] git-svn and svn cp
From: gerhard.oettl.ml @ 2007-11-19 11:11 UTC (permalink / raw)
To: git
I hope this is the correct mailing list. If not please point me in the
right direction.
I played a little with git (1.5.3.4 / debian) and had the following
observation:
Doing a "svn cp" (for example for a tag) results in a large traffic when
doing a "git-svn fetch" afterwards.
To verify I did:
git-svn clone -s svn://www.ogersoft.at/ogerlit
git-svn fetch
svn cp svn://... svn://... (one file ca 3mb)
svk checkout (a tcpflow output of about 3k - plaintext commands, I think
a svn checkout would be the same)
git-svn fetch (a tcpflow output of 700k - containing a textdelta of
nearly 700k)
So the question remains:
Does svn-git dont know about lightweight svn copies?
or can svn-git not handle them correct by now?
or did I something wrong?
thanks
gerhard
^ permalink raw reply
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Jakub Narebski @ 2007-11-19 11:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0711190320r28224763t5a6c9ed7758a12b3@mail.gmail.com>
Catalin Marinas wrote:
> On 18/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>
> > I use Stacked GIT 0.13 with git 1.5.3.5 (and Python 2.4.3).
> > StGIT does recognize old StGIT branches (and converts them),
> > but "stg branch -l" list only one branch. I guess that is
> > cause by the fact that all the rest of branches are packed.
>
> Have you tried the latest StGIT snapshot? We added support for this
> and it will be available in 0.14 (to be released pretty soon).
Would it work with Python 2.4.3? Yes, I know I should upgrade my
Linux distribution (I use now Aurox 11.1, which is based on Fedora
Core 4)...
> > Another StGIT question: how to check if given branch is controlled
> > by StGIT (needed for my bash prompt)?
>
> 'stg branch -l' lists the branches and marks those controlled by
> StGIT. For a simple test, just use a command which would fail on
> non-stgit branches (stg id base). Yet another way is to check for the
> presence of '.git/patches/<branch>'.
Thanks. 'stg id base' is quite a lot slower than
'test -e "$(git rev-parse --git-dir)/patches/$branch"', and it _does_
matter in prompt creating.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: Matthieu Moy @ 2007-11-19 12:29 UTC (permalink / raw)
To: gerhard.oettl.ml; +Cc: git
In-Reply-To: <47416F68.9070908@ogersoft.at>
gerhard.oettl.ml@ogersoft.at writes:
> I hope this is the correct mailing list. If not please point me in the
> right direction.
>
>
> I played a little with git (1.5.3.4 / debian) and had the following
> observation:
> Doing a "svn cp" (for example for a tag) results in a large traffic
> when doing a "git-svn fetch" afterwards.
>
> To verify I did:
> git-svn clone -s svn://www.ogersoft.at/ogerlit
I guess the --tags=... and --branches=... options of git-svn can help.
[ disclaimer: I never used git-svn on a repository with branches and
tags ]
--
Matthieu
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: David Kastrup @ 2007-11-19 12:50 UTC (permalink / raw)
To: git
In-Reply-To: <vpq3av25sg0.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> gerhard.oettl.ml@ogersoft.at writes:
>
>> I hope this is the correct mailing list. If not please point me in the
>> right direction.
>>
>>
>> I played a little with git (1.5.3.4 / debian) and had the following
>> observation:
>> Doing a "svn cp" (for example for a tag) results in a large traffic
>> when doing a "git-svn fetch" afterwards.
>>
>> To verify I did:
>> git-svn clone -s svn://www.ogersoft.at/ogerlit
>
> I guess the --tags=... and --branches=... options of git-svn can help.
You are aware of what the "-s" option does?
--
David Kastrup
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: Matthieu Moy @ 2007-11-19 12:56 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86k5oez9f5.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>>> To verify I did:
>>> git-svn clone -s svn://www.ogersoft.at/ogerlit
>>
>> I guess the --tags=... and --branches=... options of git-svn can help.
>
> You are aware of what the "-s" option does?
Not in the details. Well, I believe the accurate question (to original
poster) is: does your svn repository use the standard svn layout
(tags/, branches/, trunk/)?
--
Matthieu
^ permalink raw reply
* Git in a Nutshell guide
From: Jonas Juselius @ 2007-11-19 13:05 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
Hi everybody,
I have been involved in a somewhat painful process of trying to convert
a bunch of scientific programmers from being CVS users to becoming git
users. In this process I ended up writing a sort of git in a nutshell
guide for non-technical users. It struck me that this might be of
interest to others as well. I'm not a grand git wizard myself, so the
guide is probably not entirely correct in every respect. All comments
and suggestions are welcome!
I have also written a CVS2git transition guide, which outlines one
possible way of converting from CVS to git. This guide has some overlap
with the Git in a Nutshell guide, since I started with the CVS2git guide
and then realised it was not quite enough. It would probably be a good
idea to slim down the CVS2git guide, and move some of the discussion to
the Nushell guide instead. Let me know what you think. Both guides still
need quite a bit of polishing, but I hope they can be useful and
interesting in the crusade against CVS/SVN ;)If you think the guides
could benefit other users, they could maybe be posted (or at least
linked) on the git site.
The guides, including the LaTeX source, are available via gitweb:
http://git.jonas.iki.fi/gitweb.cgi?p=git_guides.git;a=summary
.jonas.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Catalin Marinas @ 2007-11-19 13:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711191257.09158.jnareb@gmail.com>
On 19/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> Catalin Marinas wrote:
> > On 18/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > > I use Stacked GIT 0.13 with git 1.5.3.5 (and Python 2.4.3).
> > > StGIT does recognize old StGIT branches (and converts them),
> > > but "stg branch -l" list only one branch. I guess that is
> > > cause by the fact that all the rest of branches are packed.
> >
> > Have you tried the latest StGIT snapshot? We added support for this
> > and it will be available in 0.14 (to be released pretty soon).
>
> Would it work with Python 2.4.3? Yes, I know I should upgrade my
> Linux distribution (I use now Aurox 11.1, which is based on Fedora
> Core 4)...
Yes, it works with Python 2.4. We deprecated the Python 2.3 support.
--
Catalin
^ permalink raw reply
* [PATCH 0/2] gitweb: CSS cleanup, part 1
From: Jakub Narebski @ 2007-11-19 13:16 UTC (permalink / raw)
To: git
This series of (independent) patches is low hanging fruit of gitweb's
CSS cleanup and fixes. In the second part I plan on large
reorganization of CSS file to make it easier to read, understand,
and modify.
Jakub Narebski (2):
gitweb: Style all tables using CSS
gitweb: Put project README in div.readme, fix its padding
Diffstat:
gitweb/gitweb.css | 8 ++++----
gitweb/gitweb.perl | 26 ++++++++++++++------------
2 files changed, 18 insertions(+), 16 deletions(-)
--
Jakub Narebski
^ permalink raw reply
* [PATCH 1/2] gitweb: Style all tables using CSS
From: Jakub Narebski @ 2007-11-19 13:16 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1195478172-17226-1-git-send-email-jnareb@gmail.com>
Remove all cellspacing="0" attributes from tables in gitweb,
replacing it by CSS rule. Add CSS classes for all tables.
While at it, change class(es) of table for commit message and commit
authorship search from "grep" to "commit_search"; similarly,
"grep_search" class is now used for table with results of grep (files)
search.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
All tables now get equivalent of 'cellspacing="0"' attribute.
gitweb/gitweb.css | 4 ----
gitweb/gitweb.perl | 22 +++++++++++-----------
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 1b88879..17c60e4 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -170,14 +170,10 @@ a.text:hover {
table {
padding: 8px 4px;
-}
-
-table.project_list {
border-spacing: 0;
}
table.diff_tree {
- border-spacing: 0;
font-family: monospace;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e788ef9..3d532dc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3544,7 +3544,7 @@ sub git_shortlog_body {
$from = 0 unless defined $from;
$to = $#{$commitlist} if (!defined $to || $#{$commitlist} < $to);
- print "<table class=\"shortlog\" cellspacing=\"0\">\n";
+ print "<table class=\"shortlog\">\n";
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my %co = %{$commitlist->[$i]};
@@ -3590,7 +3590,7 @@ sub git_history_body {
$from = 0 unless defined $from;
$to = $#{$commitlist} unless (defined $to && $to <= $#{$commitlist});
- print "<table class=\"history\" cellspacing=\"0\">\n";
+ print "<table class=\"history\">\n";
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my %co = %{$commitlist->[$i]};
@@ -3650,7 +3650,7 @@ sub git_tags_body {
$from = 0 unless defined $from;
$to = $#{$taglist} if (!defined $to || $#{$taglist} < $to);
- print "<table class=\"tags\" cellspacing=\"0\">\n";
+ print "<table class=\"tags\">\n";
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my $entry = $taglist->[$i];
@@ -3713,7 +3713,7 @@ sub git_heads_body {
$from = 0 unless defined $from;
$to = $#{$headlist} if (!defined $to || $#{$headlist} < $to);
- print "<table class=\"heads\" cellspacing=\"0\">\n";
+ print "<table class=\"heads\">\n";
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my $entry = $headlist->[$i];
@@ -3750,7 +3750,7 @@ sub git_search_grep_body {
$from = 0 unless defined $from;
$to = $#{$commitlist} if (!defined $to || $#{$commitlist} < $to);
- print "<table class=\"grep\" cellspacing=\"0\">\n";
+ print "<table class=\"commit_search\">\n";
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my %co = %{$commitlist->[$i]};
@@ -3891,7 +3891,7 @@ sub git_summary {
git_print_page_nav('summary','', $head);
print "<div class=\"title\"> </div>\n";
- print "<table cellspacing=\"0\">\n" .
+ print "<table class=\"projects_list\">\n" .
"<tr><td>description</td><td>" . esc_html($descr) . "</td></tr>\n" .
"<tr><td>owner</td><td>" . esc_html($owner) . "</td></tr>\n";
if (defined $cd{'rfc2822'}) {
@@ -3965,7 +3965,7 @@ sub git_tag {
git_print_header_div('commit', esc_html($tag{'name'}), $hash);
print "<div class=\"title_text\">\n" .
- "<table cellspacing=\"0\">\n" .
+ "<table class=\"object_header\">\n" .
"<tr>\n" .
"<td>object</td>\n" .
"<td>" . $cgi->a({-class => "list", -href => href(action=>$tag{'type'}, hash=>$tag{'object'})},
@@ -4405,7 +4405,7 @@ sub git_tree {
}
git_print_page_path($file_name, 'tree', $hash_base);
print "<div class=\"page_body\">\n";
- print "<table cellspacing=\"0\">\n";
+ print "<table class=\"tree\">\n";
my $alternate = 1;
# '..' (top directory) link if possible
if (defined $hash_base &&
@@ -4627,7 +4627,7 @@ sub git_commit {
git_print_header_div('tree', esc_html($co{'title'}) . $ref, $co{'tree'}, $hash);
}
print "<div class=\"title_text\">\n" .
- "<table cellspacing=\"0\">\n";
+ "<table class=\"object_header\">\n";
print "<tr><td>author</td><td>" . esc_html($co{'author'}) . "</td></tr>\n".
"<tr>" .
"<td></td><td> $ad{'rfc2822'}";
@@ -5226,7 +5226,7 @@ sub git_search {
git_print_page_nav('','', $hash,$co{'tree'},$hash);
git_print_header_div('commit', esc_html($co{'title'}), $hash);
- print "<table cellspacing=\"0\">\n";
+ print "<table class=\"pickaxe search\">\n";
my $alternate = 1;
$/ = "\n";
my $git_command = git_cmd_str();
@@ -5293,7 +5293,7 @@ sub git_search {
git_print_page_nav('','', $hash,$co{'tree'},$hash);
git_print_header_div('commit', esc_html($co{'title'}), $hash);
- print "<table cellspacing=\"0\">\n";
+ print "<table class=\"grep_search\">\n";
my $alternate = 1;
my $matches = 0;
$/ = "\n";
--
1.5.3.5
^ permalink raw reply related
* [PATCH 2/2] gitweb: Put project README in div.readme, fix its padding
From: Jakub Narebski @ 2007-11-19 13:16 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1195478172-17226-1-git-send-email-jnareb@gmail.com>
Put (optional) projects README on "summary" page in <div> element
using "readme" class. This allow to style it using CSS.
Add padding to project's README to make it line out with the rest
of the page.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.css | 4 ++++
gitweb/gitweb.perl | 4 +++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 17c60e4..446a1c3 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -85,6 +85,10 @@ div.title, a.title {
color: #000000;
}
+div.readme {
+ padding: 8px;
+}
+
a.title:hover {
background-color: #d9d8d1;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3d532dc..491a3f4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3912,8 +3912,10 @@ sub git_summary {
if (-s "$projectroot/$project/README.html") {
if (open my $fd, "$projectroot/$project/README.html") {
- print "<div class=\"title\">readme</div>\n";
+ print "<div class=\"title\">readme</div>\n" .
+ "<div class=\"readme\">\n";
print $_ while (<$fd>);
+ print "\n</div>\n"; # class="readme"
close $fd;
}
}
--
1.5.3.5
^ permalink raw reply related
* Re: [user] git-svn and svn cp
From: Benoit Sigoure @ 2007-11-19 13:20 UTC (permalink / raw)
To: gerhard.oettl.ml; +Cc: David Kastrup, Git Mailing List, Matthieu Moy
In-Reply-To: <vpqzlxa2y2f.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On Nov 19, 2007, at 1:56 PM, Matthieu Moy wrote:
> David Kastrup <dak@gnu.org> writes:
>
>> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>>
>>>> To verify I did:
>>>> git-svn clone -s svn://www.ogersoft.at/ogerlit
>>>
>>> I guess the --tags=... and --branches=... options of git-svn can
>>> help.
>>
>> You are aware of what the "-s" option does?
I personally don't know and I went through the code to see that it's
an (undocumented) alias for --stdlayout.
> Not in the details. Well, I believe the accurate question (to original
> poster) is: does your svn repository use the standard svn layout
> (tags/, branches/, trunk/)?
I think this is irrelevant to the question he asked.
Now I think that the fact that SVN does "lightweight" copies by
recording that such modification was in fact an `svn cp' / `svn mv'
isn't important for git-svn, because the data end up in the Git
repository which handles copies and moves much much better than SVN
does. But here the concerns raised by Gerhard seem to be more
network-wise, in which case I don't know. I looked at the code,
things seem to happen under the hood of Git::SVN::Fetcher but I don't
see what can be optimized (the code isn't trivial). Most of the
access are done through the underlying SVN Perl bindings, so if
someone knows how to use them better, I think Eric will be eager to
see the patches :)
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: gerhard.oettl.ml @ 2007-11-19 13:34 UTC (permalink / raw)
Cc: Git Mailing List
In-Reply-To: <EB96D9F3-D69C-4D46-961C-27885CBC0E52@lrde.epita.fr>
Benoit Sigoure schrieb:
> On Nov 19, 2007, at 1:56 PM, Matthieu Moy wrote:
> I think this is irrelevant to the question he asked.
>
> Now I think that the fact that SVN does "lightweight" copies by
> recording that such modification was in fact an `svn cp' / `svn mv'
> isn't important for git-svn, because the data end up in the Git
> repository which handles copies and moves much much better than SVN
> does.
I hoped this and it was one of the motivations for looking at git ;-)
But why is so much traffic necessary to transfer data that is already
_complete_ present in the local git repository?
Traffic that seams not to be necessary when using the "not so good" svn.
gerhard
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-clone manpage not to refer to itself
From: Johannes Schindelin @ 2007-11-19 13:35 UTC (permalink / raw)
To: Sergei Organov; +Cc: git, gitster
In-Reply-To: <87ejeq1131.fsf@osv.gnss.ru>
Hi,
On Fri, 16 Nov 2007, Sergei Organov wrote:
> +ifndef::git-clone[]
It is laudable that you want to fix the _generated_ documentation, but
there are two things to keep in mind:
- it does _nothing_ to help readers of the sources, and asciidoc was
chosen purposely because the source is human-readable, and
- it makes writing the perl script to do a very tiny subset of asciidoc
formatting much harder. We encounter enough problems with the different
versions of asciidoc/docbook combinations that I think this perl script
would be actually useful.
I know that the user manual uses some advanced features, too, but it did
not use ifdef in the main text, for example, let alone nested ifdefs,
which your patch would encourage much more than the source before.
Ciao,
Dscho
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jakub Narebski @ 2007-11-19 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <1195477504.8093.15.camel@localhost>
A few comments (from what I checked so far):
1. It is "man git-checkout" (or "git checkout --help"),
not "man git checkout"
2. Instead of using 'verbatim' environment directly to show example CLI
session it would be I think better to define verbatim-like environment
for this ('example', 'commands', 'CLI', 'session'); perhaps replacing
verbatim by lstlisting from the listings/lstlisting package for syntax
highlighting.
I'll send more comments after reading it in full...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: David Kastrup @ 2007-11-19 13:37 UTC (permalink / raw)
To: git
In-Reply-To: <474190EB.2090701@ogersoft.at>
gerhard.oettl.ml@ogersoft.at writes:
> Benoit Sigoure schrieb:
>> On Nov 19, 2007, at 1:56 PM, Matthieu Moy wrote:
>
>> I think this is irrelevant to the question he asked.
>>
>> Now I think that the fact that SVN does "lightweight" copies by
>> recording that such modification was in fact an `svn cp' / `svn mv'
>> isn't important for git-svn, because the data end up in the Git
>> repository which handles copies and moves much much better than SVN
>> does.
>
> I hoped this and it was one of the motivations for looking at git ;-)
>
> But why is so much traffic necessary to transfer data that is
> already _complete_ present in the local git repository?
Is it? What is the right behavior when the file has been changed
within the git repository (after all, we are rebasing and not tracking
the svn archive)?
While I would probably prefer getting a copy from the changed file
rather than the original one, the matter does not seem completely
trivial in its implications.
> Traffic that seams not to be necessary when using the "not so good"
> svn.
It is not a git problem (git has good packing properties) but rather a
git-svn issue. So don't blame git in general.
--
David Kastrup
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: Matthieu Moy @ 2007-11-19 13:49 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: gerhard.oettl.ml, David Kastrup, Git Mailing List
In-Reply-To: <EB96D9F3-D69C-4D46-961C-27885CBC0E52@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>> Not in the details. Well, I believe the accurate question (to original
>> poster) is: does your svn repository use the standard svn layout
>> (tags/, branches/, trunk/)?
>
> I think this is irrelevant to the question he asked.
Well, I'm far enough from being a git-svn expert, but I suppose
git-svn will special-case the content of tags/ and branches/
directories, and consider copies there to be tags and branches. I
don't know whether git-svn does it efficiently, though.
If you use "svn copy" with the meaning "create a tag" with a
destination other than tags/ directory, then, git-svn can not guess it
was actually a tag.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-clone manpage not to refer to itself
From: Jakub Narebski @ 2007-11-19 14:03 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711191430460.16728@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Fri, 16 Nov 2007, Sergei Organov wrote:
>
>> +ifndef::git-clone[]
>
> It is laudable that you want to fix the _generated_ documentation, but
> there are two things to keep in mind:
>
> - it does _nothing_ to help readers of the sources, and asciidoc was
> chosen purposely because the source is human-readable, and
IMHO it doesn't make source of documentation less readable.
It has the advantage of not duplicating contents, and being a bit mre
readable than writing "for <cmd>" in documentation contents.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: Benoit Sigoure @ 2007-11-19 14:04 UTC (permalink / raw)
To: Matthieu Moy; +Cc: gerhard.oettl.ml, David Kastrup, Git Mailing List
In-Reply-To: <vpqtzni1h17.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]
On Nov 19, 2007, at 2:49 PM, Matthieu Moy wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>>> Not in the details. Well, I believe the accurate question (to
>>> original
>>> poster) is: does your svn repository use the standard svn layout
>>> (tags/, branches/, trunk/)?
>>
>> I think this is irrelevant to the question he asked.
>
> Well, I'm far enough from being a git-svn expert, but I suppose
> git-svn will special-case the content of tags/ and branches/
> directories, and consider copies there to be tags and branches. I
> don't know whether git-svn does it efficiently, though.
>
> If you use "svn copy" with the meaning "create a tag" with a
> destination other than tags/ directory, then, git-svn can not guess it
> was actually a tag.
No, git-svn only needs to know where to look for branches and tags so
that it can replicate them on the Git side by creating remote
branches. It has nothing to do with the fact that a tag or a branch
happen to be a copy of something else (which isn't necessarily true,
I can perfectly create a tag out of the blue which has its own unique
content, same thing for branches).
The question of Gerhard was thus, why do we need to transfer "so
much" data over the network when we should be able to guess that the
data is already in the Git repo (because git-svn can figure out that
something is a copy of something else -- because SVN records this
information -- and thus save the network from downloading useless
deltas). It's possible that the code can be optimized to handle
this, or so I guess.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ 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