* Re: GIT 0.99.9
From: Horst von Brand @ 2005-10-31 3:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Junio C Hamano, git
In-Reply-To: <20051030202322.A65D2353CD1@atlas.denx.de>
Wolfgang Denk <wd@denx.de> wrote:
> In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
> > I hate it when somebody tells me "it works for me", but I cannot
> > help you here, sorry. I'm no rpm expert and the "make rpm" rule
> > seems to work for me.
> Which environment (Linux distribution) did you test this on? I tried
> Fedora Core 2 and 4, both with the same result. I get the same
> problem when building from the git source tree or when using the
> source RPM.
In Fedora rawhide it works (I've got asciidoc installed, and git locally in
my account).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Archaeology [Was: Re: GIT 0.99.9]
From: Horst von Brand @ 2005-10-31 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7v4q6yl6wv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> One good thing to have would be to add a section to Tutorial.
> Currently we cover building a small project from scratch and
> have the readers graduate when they learn basic commit swapping,
> but we do not talk much about archaeology tools.
One of the problems with that is to have a sufficiently rich repository at
hand. People who futz around with git could be directed to get the latest
git from git for a guided tour.
Or create a script like the one in the cogito tutorial to build up someting
interesting and then direct people to look it over.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Horst von Brand @ 2005-11-01 23:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Chris Wright, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510310819290.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Mon, 31 Oct 2005, H. Peter Anvin wrote:
> > The git-core RPM definitiely needs to be split. Doubly ironic that it's
> > called "core".
> I don't think it's necessarily ironic. It's actually a good thing.
>
> I think that what we want to have is one _project_ (called "git"), which
> can generate multiple RPM's ("git-core", "git-svnimport", "git-docs",
> whatever).
Better cut along outside requirements: git-svn, git-cvs, git-scm-du-jour,
git-gtk. Please _don't_ split out documentation.
> So I think it was good that we called the RPM "git-core". We've just not
> yet done the obvious thing to create a few _other_ RPM's.
Right.
> Now, I'm not certain how happy RPM would be with having one source RPM
> generate multiple binary RPM's,
Works fine. It is exactly what is used to build -devel packages. What
doesn't work is doing multiple architectures, e.g. creating
git-core-1.2.3.i386.rpm and git-gitk-1.2.3.noarch.rpm, in one go.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Horst von Brand @ 2005-11-01 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> I do not know much about how things are done in the RPM world,
> but is there a concept of "the upstream" vs "packaging
> maintainer" there? IOW, are the majority of RPM binary packages
> done by the upstream maintainer?
No, they aren't. RPM is set up so you can take the vanilla upstream package
and add local patches, special configuration, ... at will downstream.
>
> I am currently generating i386 RPMs and i386 debs myself but I
> am not particularly proud of the current setup. I do not have
> an RPM based machine that I can install the result myself to
> test (which is what started this thread). Since I am not a
> Debian developer (and I do not particularly wish to become one
> myself), the debs I generate will not be official anyway.
> Personally I'd be happier if I can just lose rpm and deb targets
> from the "upstream" Makefile (git-core.spec file and debian/
> subdirectory as well while we are at it), ask "packaging
> maintainers" to pull from kernel.org/ tree and do RPMs and Debs
> outside.
Please keep the git-core.spec file, it is useful to be able to build RPMs
directly from the tarball.
[...]
> One thing we could do without breaking much of the current
> arrangement is to have a team of people to help porting for
> major packaging formats (RPMs and Debs mostly but I know we have
> OpenBSD and Darwin people here too), and ask them to feed me the
> updates to rpm/deb/whatever target in the Makefile as needed.
> Especially before a major release I could ask them to test
> things out and generate binary packages, perhaps taken out of
> the tip of the master branch, or even another "for-porters"
> branch for this purpose.
Good idea. Will build RPMs regularly then.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Horst von Brand @ 2005-11-01 23:56 UTC (permalink / raw)
To: Martin Langhoff
Cc: Joel Becker, Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <46a038f90510311228v50743158q80d79e963bd503ce@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
[...]
> In practice, a new developer will often roll up commits to avoid
> sending a string of shameful patches and corrections on top -- I often
> do that ;-) . Developers with more "mana" will have published repos
> where Junio pulls directly from -- and they get merged with full
> history. Of course -- they don't have brown-paper-bag commits like I
> do...
I bet they have a scratchpad on their laptop (full of brown-paper-bag
commits and backtracking) from which they push into a cleaned up repository
for public consumption.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] Gitweb: Per-head rss feeds and per-project opml.
From: Penny Leach @ 2005-11-02 2:03 UTC (permalink / raw)
To: git
In-Reply-To: <11308969914190-git-send-email-penny@catalyst.net.nz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry, I should have said that this can be seen here:
http://locke.catalyst.net.nz/gitweb
Penny Leach wrote:
> Signed-off-by: Penny Leach <penny@catalyst.net.nz>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFDaB5rGHUSCqMOwisRAntNAJ9bt4VgMCcK6LVTSPt8Hr2KuRCq6ACgq26o
DneB+AI6jlPLabIL0Bikm3o=
=4rH6
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] Gitweb: Per-head rss feeds and per-project opml.
From: Penny Leach @ 2005-11-02 2:03 UTC (permalink / raw)
To: git; +Cc: Penny Leach
Signed-off-by: Penny Leach <penny@catalyst.net.nz>
---
gitweb.cgi | 104 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 91 insertions(+), 13 deletions(-)
ad295087a0969c6816d6acf57f39053666327f2e
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -52,12 +52,18 @@ if (defined $action) {
if ($action eq "git-logo.png") {
git_logo();
exit;
- } elsif ($action eq "opml") {
- git_opml();
- exit;
}
}
+my $show_rss = 0;
+my $show_opml = 0;
+if (!defined($action) || $action eq 'summary' || $action eq 'heads' || $action eq 'log' || $action eq 'shortlog') {
+ $show_rss = 1;
+}
+if (!defined($action) || $action eq 'summary') {
+ $show_opml = 1;
+}
+
my $order = $cgi->param('o');
if (defined $order) {
if ($order =~ m/[^0-9a-zA-Z_]/) {
@@ -80,11 +86,17 @@ if (defined $project) {
undef $project;
die_error(undef, "No such project.");
}
- $rss_link = "<link rel=\"alternate\" title=\"$project log\" href=\"$my_uri?p=$project;a=rss\" type=\"application/rss+xml\"/>";
+
+ if ($show_rss) {
+ $rss_link = "<link rel=\"alternate\" title=\"$project log\" href=\"$my_uri?p=$project;a=rss\" type=\"application/rss+xml\"/>";
+ }
+
$ENV{'GIT_DIR'} = "$projectroot/$project";
} else {
- git_project_list();
- exit;
+ if (!defined($action)) {
+ git_project_list();
+ exit;
+ }
}
my $file_name = $cgi->param('f');
@@ -96,11 +108,16 @@ if (defined $file_name) {
}
my $hash = $cgi->param('h');
+my $rsshead;
if (defined $hash) {
$hash = validate_input($hash);
if (!defined($hash)) {
die_error(undef, "Invalid hash parameter.");
}
+ if ($show_rss) { #override it
+ $rss_link = "<link rel=\"alternate\" title=\"$project#$hash log\" href=\"$my_uri?p=$project;a=rss;h=$hash\" type=\"application/rss+xml\"/>";
+ }
+ $rsshead = $hash;
}
my $hash_parent = $cgi->param('hp');
@@ -202,6 +219,10 @@ if (!defined $action || $action eq "summ
} elsif ($action eq "tag") {
git_tag();
exit;
+# moved to here so $project gets validated first
+} elsif ($action eq "opml") {
+ git_opml();
+ exit;
} else {
undef $action;
die_error(undef, "Unknown action.");
@@ -280,6 +301,13 @@ a.rss_logo {
color:#ffffff; background-color:#ff6600;
font-weight:bold; font-family:sans-serif; font-size:10px;
text-align:center; text-decoration:none;
+ margin:2px;
+}
+a.rss_logo_small {
+ border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
+ color:#ffffff; background-color:#ff6600;
+ font-weight:bold; font-family:sans-serif; font-size:10px;
+ text-align:center; text-decoration:none;
}
a.rss_logo:hover { background-color:#ee5500; }
</style>
@@ -327,9 +355,21 @@ sub git_footer_html {
if (defined $descr) {
print "<div class=\"page_footer_text\">" . escapeHTML($descr) . "</div>\n";
}
- print $cgi->a({-href => "$my_uri?p=$project;a=rss", -class => "rss_logo"}, "RSS") . "\n";
+ if ($show_rss) {
+ if (defined($rsshead)) {
+ print $cgi->a({-href => "$my_uri?p=$project;a=rss;h=$rsshead", -class => "rss_logo"}, "RSS") . "\n";
+ } else {
+ print $cgi->a({-href => "$my_uri?p=$project;a=rss", -class => "rss_logo"}, "RSS") . "\n";
+ }
+ }
+ if ($show_opml) {
+ print $cgi->a({-href => "$my_uri?p=$project;a=opml", -class => "rss_logo"}, "OPML") . "\n";
+ }
+
} else {
- print $cgi->a({-href => "$my_uri?a=opml", -class => "rss_logo"}, "OPML") . "\n";
+ if ($show_opml) {
+ print $cgi->a({-href => "$my_uri?a=opml", -class => "rss_logo"}, "OPML") . "\n";
+ }
}
print "</div>\n" .
"</body>\n" .
@@ -864,6 +904,7 @@ sub git_project_list {
$cgi->a({-href => "$my_uri?p=$pr->{'path'};a=summary"}, "summary") .
" | " . $cgi->a({-href => "$my_uri?p=$pr->{'path'};a=shortlog"}, "shortlog") .
" | " . $cgi->a({-href => "$my_uri?p=$pr->{'path'};a=log"}, "log") .
+ " | " . $cgi->a({-href => "$my_uri?p=$pr->{'path'};a=opml", -class => "rss_logo_small"}, "OPML") .
"</td>\n" .
"</tr>\n";
}
@@ -1095,6 +1136,7 @@ sub git_summary {
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?p=$project;a=shortlog;h=$tag{'name'}"}, "shortlog") .
" | " . $cgi->a({-href => "$my_uri?p=$project;a=log;h=$tag{'name'}"}, "log") .
+ " | " . $cgi->a({-href => "$my_uri?p=$project;a=rss;h=$tag{'name'}", -class => "rss_logo_small"}, "RSS") .
"</td>\n" .
"</tr>";
} else {
@@ -1240,6 +1282,7 @@ sub git_heads {
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?p=$project;a=shortlog;h=$tag{'name'}"}, "shortlog") .
" | " . $cgi->a({-href => "$my_uri?p=$project;a=log;h=$tag{'name'}"}, "log") .
+ " | " . $cgi->a({-href => "$my_uri?p=$project;a=rss;h=$tag{'name'}", -class => "rss_logo_small"}, "RSS") .
"</td>\n" .
"</tr>";
}
@@ -1428,16 +1471,31 @@ sub git_tree {
sub git_rss {
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
- open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 " . git_read_hash("$project/HEAD") or die_error(undef, "Open failed.");
+ my $read_hash;
+ if (!defined($hash)) {
+ $read_hash = git_read_hash("$project/HEAD");
+ } else {
+ $read_hash = $hash;
+ }
+
+ open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 $read_hash " or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading rev-list failed.");
print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
"<rss version=\"2.0\" xmlns:content=\"http://purl.org/rss/1.0/modules/content/\">\n";
print "<channel>\n";
- print "<title>$project</title>\n".
- "<link>" . escapeHTML("$my_url?p=$project;a=summary") . "</link>\n".
- "<description>$project log</description>\n".
+ my $title = $project;
+ my $link = escapeHTML("$my_url?p=$project;a=summary");
+ my $description = "$project log";
+ if (defined($hash)) {
+ $title .= "#$hash";
+ $link .= escapeHTML(";h=$hash");
+ $description = $project."#".$hash." log";
+ }
+ print "<title>$title</title>\n".
+ "<link>$link</link>\n".
+ "<description>$description</description>\n".
"<language>en</language>\n";
for (my $i = 0; $i <= $#revlist; $i++) {
@@ -1482,7 +1540,13 @@ sub git_rss {
}
sub git_opml {
- my @list = git_read_projects();
+ my @list;
+
+ if (defined($project)) {
+ @list = ( { 'path' => $project } );
+ } else {
+ @list = git_read_projects();
+ }
print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
@@ -1509,6 +1573,20 @@ sub git_opml {
my $rss = "$my_url?p=$proj{'path'};a=rss";
my $html = "$my_url?p=$proj{'path'};a=summary";
print "<outline type=\"rss\" text=\"$path\" title=\"$path\" xmlUrl=\"$rss\" htmlUrl=\"$html\"/>\n";
+
+ $project = $proj{'path'};
+ my $taglist = git_read_refs('refs/heads');
+
+ if (defined @$taglist) {
+ foreach my $entry (@$taglist) {
+ my %tag = %$entry;
+ my $path = escapeHTML(chop_str($proj{'path'}.'#'.$tag{'name'},25,5));
+ my $rss = "$my_url?p=$proj{'path'};h=$tag{'name'};a=rss";
+ my $html = "$my_url?p=$proj{'path'};h=$tag{'name'};a=summary";
+ print "<outline type=\"rss\" text=\"$path\" title=\"$path\" xmlUrl=\"$rss\" htmlUrl=\"$html\"/>\n";
+ }
+ }
+
}
print "</outline>\n".
"</body>\n".
^ permalink raw reply
* Clone a repository with only the objects needed for a single tag
From: Ben Lau @ 2005-11-02 2:02 UTC (permalink / raw)
To: git
Hi,
Is there any method to clone/copy a repository with only the objects
needed
for a single tag in order to save disk space?
For example, if I want to start a new project based on a specific
version of kernel
like v2.6.14. I would run `git-clone` and then checkout a new branch
based on the tag.
However, one of the development host is a notebook computer which has
only 2GB space
leave. Therefore I hope the space occupied by the respository could be
mininiumized
while it keeps to be able to fetch/update from my master repository.
Thanks for any advise.
^ permalink raw reply
* Re: HTTP pushes
From: Johannes Schindelin @ 2005-11-02 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1z51id.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 1 Nov 2005, Junio C Hamano wrote:
> I had an impression that DAV has its own notion of version
> control, so using git as a backend on the server side might be
> an interesting exercise.
IIRC Subversion can operate over DAV, too.
Ciao,
Dscho
^ permalink raw reply
* Re: HTTP pushes
From: Nick Hengeveld @ 2005-11-02 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v1x1z51id.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 01, 2005 at 04:36:42PM -0800, Junio C Hamano wrote:
> I had an impression that DAV has its own notion of version
> control, so using git as a backend on the server side might be
> an interesting exercise.
There are versioning extensions to DAV, but they're not supported in all
implementations - for example, Apache's mod_dav only supports the
distributed authoring methods and that's what I've been testing with.
Pushing should work fine to a version-aware DAV server, although the
push should fail if the repository files are version-controlled (they
don't have to be, and it wouldn't make sense for them to be anyway.)
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH] cvsimport: cvsps should be quiet too
From: Martin Langhoff @ 2005-11-02 0:53 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Tell cvsps to be quite, unless we've been told to be verbose.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-cvsimport.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 3b008080b6ab6077e6dd2178c01dee4efed8ef42
720675e4ad1e4efcda6af41461cf264617194ffc
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 0144670..7bd9136 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -491,6 +491,7 @@ unless($pid) {
my @opt;
@opt = split(/,/,$opt_p) if defined $opt_p;
unshift @opt, '-z', $opt_z if defined $opt_z;
+ unshift @opt, '-q' unless defined $opt_v;
unless (defined($opt_p) && $opt_p =~ m/--no-cvs-direct/) {
push @opt, '--cvs-direct';
}
---
0.99.8.GIT
^ permalink raw reply related
* Re: HTTP pushes
From: David Lang @ 2005-11-02 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v1x1z51id.fsf@assigned-by-dhcp.cox.net>
On Tue, 1 Nov 2005, Junio C Hamano wrote:
>> I think this is useful. There are restrictive firewalls out there, which
>> only allow ports 80 and 443 to be connected to. Your work would fit in
>> right there.
>
> Another solution for this would be to allow connect.c to use a
> HTTP connect passthru proxy. CVS does this with an ugly but easy
> to understand notation:
>
> ':pserver;proxy=firewall;proxyport=3128:user@host:/path/to/repo
>
please note that there are firewalls out there that don't let you use port
443 (and the connect command) as a free pass to do anything you want. They
verify that you at least do a valid SSL handshake immediatly after or they
figure you are trying to bypass them and shut you down.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* [PATCH] cvsimport: introduce -P <cvsps-output-file> option
From: Martin Langhoff @ 2005-11-02 0:48 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
-P:: <cvsps-output-file>
Instead of calling cvsps, read the provided cvsps output file. Useful
for debugging or when cvsps is being handled outside cvsimport.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Documentation/git-cvsimport.txt | 4 ++++
git-cvsimport.perl | 12 ++++++++----
2 files changed, 12 insertions(+), 4 deletions(-)
applies-to: a0f3f0cdfb22033b0dd52a0abc7c5cebfc17e56d
16f5165e7258fcd0dc209f7eb4e85d4222ecaaa4
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index f5248c9..a2f97b3 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -60,6 +60,10 @@ the old cvs2git tool.
+
If you need to pass multiple options, separate them with a comma.
+-P:: <cvsps-output-file>
+ Instead of calling cvsps, read the provided cvsps output file. Useful
+ for debugging or when cvsps is being handled outside cvsimport.
+
-m::
Attempt to detect merges based on the commit message. This option
will enable default regexes that try to capture the name source
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e3cad5a..0144670 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,7 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_s,$opt_m,$opt_M);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M);
sub usage() {
print STDERR <<END;
@@ -41,7 +41,7 @@ END
exit(1);
}
-getopts("hivmkuo:d:p:C:z:s:M:") or usage();
+getopts("hivmkuo:d:p:C:z:s:M:P:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -494,8 +494,12 @@ unless($pid) {
unless (defined($opt_p) && $opt_p =~ m/--no-cvs-direct/) {
push @opt, '--cvs-direct';
}
- exec("cvsps",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
- die "Could not start cvsps: $!\n";
+ if ($opt_P) {
+ exec("cat", $opt_P);
+ } else {
+ exec("cvsps",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
+ die "Could not start cvsps: $!\n";
+ }
}
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] cvsimport: catch error condition where cvs host disappears
From: Martin Langhoff @ 2005-11-02 0:48 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Add error handling for cases where the cvs server goes away unexpectedly.
While I don't know why the cvs server is so erratic, we should definitely
exit here before committing bogus files.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-cvsimport.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
applies-to: 5184f41aebc18fdd90c27b76b8fb230fda58fb84
2f441d6598e78b59181a084f9db5be7993971602
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index bbb83fb..e3cad5a 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -337,6 +337,10 @@ sub file {
}
close ($fh);
+ if ($res eq '') {
+ die "Looks like the server has gone away while fetching $fn $rev -- exiting!";
+ }
+
return ($name, $res);
}
---
0.99.8.GIT
^ permalink raw reply related
* Re: HTTP pushes
From: Junio C Hamano @ 2005-11-02 0:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511012008310.11979@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 31 Oct 2005, Nick Hengeveld wrote:
>
>> HTTP is currently listed as a read-only/unsupported method for doing
>> pushes, is that due to inherent problems with HTTP or just because
>> it hasn't been written yet?
>>
>> I've built a working prototype of an HTTP push implementation using DAV.
I had an impression that DAV has its own notion of version
control, so using git as a backend on the server side might be
an interesting exercise.
> I think this is useful. There are restrictive firewalls out there, which
> only allow ports 80 and 443 to be connected to. Your work would fit in
> right there.
Another solution for this would be to allow connect.c to use a
HTTP connect passthru proxy. CVS does this with an ugly but easy
to understand notation:
':pserver;proxy=firewall;proxyport=3128:user@host:/path/to/repo
^ permalink raw reply
* Re: git-pull - strange (copy/rename) messages ?!
From: Junio C Hamano @ 2005-11-02 0:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git
In-Reply-To: <20051101233647.GC1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> In case of my proposal, you get the mv and cp as usual, since there are
> no multiple rename candidates for A.
I think showing things the Pasky way may be the easiest to
understand for this particular case and for the simplest case.
The original one would become something like this:
copy Graphics/{PaletteGroups.cs => PaletteCategories.cs} (80%)
copy Graphics/PaletteGroups.cs => Plot/Dialogs/Dialog.cs (75%)
...
copy Graphics/PaletteGroups.cs => Runtime/Scripting/Script.cs (75%)
copy Graphics/PaletteGroups.cs => Runtime/Scripting/ScriptLibrary.cs (64%)
delete Graphics/PaletteGroups.cs
That is, if you are interested in Plot/Dialogs/Dialog.cs, you
know where it came from. If you are interested in
Graphics/PaletteGroups.cs, you can tell it disappeared.
That is, you need to look at only one line to know what funny
things happened to one path.
However, I suspect that this requires moderate amount of surgery
on the diff output routine (the last stage). I have a feeling
that git-apply may also need to be told about it when applying
such a patch.
The biggest drawback doing things the Pasky way would be that
the textual diff would need to contain the whole file removal of
Graphics/PaletteGroups.cs. Do we want to bloat the output for
this? I personally do not think it is worth it.
We could cheat by only changing the git-apply --summary side, to
implement either Pasky or Daniel proposal, but that would make
output from 'git-diff -p | git-apply --summary' and 'git-diff -r
--name-status -r' inconsistent, which I'd rather avoid.
I think all three (i.e. current, Pasky, Daniel) logically make
sense, and it is to a certain degree just a matter of personal
taste. Let's try doing nothing for now and see if people get
used to it ;-).
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Kay Sievers @ 2005-11-02 0:26 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: Martin Langhoff, Petr Baudis, git
In-Reply-To: <20051102001206.GA21671@pe.Belkin>
On Tue, Nov 01, 2005 at 07:12:06PM -0500, Chris Shoemaker wrote:
> On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
> > On 11/2/05, Petr Baudis <pasky@suse.cz> wrote:
> > > What about having the color indicate the number of affected files (let's
> > > say on a blue..red scale) and the width the size of patch?
> >
> > I'm a /little bit/ colour blind on the red scale -- so I vote for 2
> > bars, each half the heigth of the current bar. ;-)
>
> I was going to use two bars for add vs. delete, but this could work,
> too. I'm intending on getting back to this ASAP, but for now my
> cvsimport problems are higher priority (see other post).
Guys, I'm not convinced, that we should make gitweb look like Konqueror. :)
Kay
^ permalink raw reply
* Re: [PATCH 3/4] Server-side support for user-relative paths.
From: Junio C Hamano @ 2005-11-02 0:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051101225921.3835C5BF73@nox.op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Remove the redundant code from {receive,upload}-pack.c in favour of the
> library code in path.c (previous patch) with documentation of the changes
> to the affected programs.
I like the simplification of these two calling sites, but it
makes me feel uneasy to see the workhorse named is_git_repo().
The name implies a check to see if the given path is a git repo
or not (i.e. side-effect free predicate), while what it actually
does are three things: (1) resolve and check, (2) chdir to it,
(3) set up GIT_DIR environment. Not that I have a better name
in mind...
> + SSH Is the default transport protocol and also supports an
Just a typo ("Is")?
^ permalink raw reply
* Re: [PATCH 2/4] Library code for user-relative paths.
From: Junio C Hamano @ 2005-11-02 0:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051101225921.2C6035BA82@nox.op5.se>
Andreas Ericsson <ae@op5.se> writes:
> + if((slash = strchr(dir, '/'))) {
> + *slash = '\0';
> + pw = getpwnam(dir);
> + *slash = '/';
Should you be writing into *slash when dir and path are const
char *? I know strchr returns "char *" and the compiler would
not complain but this sounds somewhat yucky.
> + if(slash && *slash + 1)
I think you mean "if (slash && slash[1])" here. While we are at
it, please have a SP betweeen if and open parenthesis.
> + dir = slash + 1;
> + else
> + dir = current_dir();
> + }
> +
> + /* ~foo/path/to/repo is now path/to/repo and we're in foo's homedir */
> + if(chdir(dir) < 0)
> + return NULL;
Hmm. It's not wrong, but "dir = current_dir()" immediately
followed by "chdir(dir)" does not feel right.
^ permalink raw reply
* Re: [PATCH 1/4] Client side of user-relative paths, take two.
From: Junio C Hamano @ 2005-11-02 0:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051101225921.245595BF70@nox.op5.se>
Andreas Ericsson <ae@op5.se> writes:
> + if (protocol == PROTO_SSH && colon && (!path || colon < path)) {
> + *colon = 0;
> + path = colon + 1;
> + }
I think "colon < path" is to cover "git://host.xz/foo/bar:baz"
case (i.e. funny directory name with an embedded colon); I think
you should reset colon to NULL if you do things differently
later depending on colon is set or not, like this part:
> + /* null-terminate host part and point path to ~ for URL's like this:
> + * ssh://host.xz/~user/repo
> + */
> + if(!colon && *(path + 1) == '~')
> + *path++ = '\0';
> + else {
> + colon = path;
> + path = strdup(path);
> + *colon = '\0';
^ permalink raw reply
* Re: [PATCH 4/4] git-daemon support for user-relative paths.
From: Junio C Hamano @ 2005-11-02 0:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051101225921.3E7455BF74@nox.op5.se>
Andreas Ericsson <ae@op5.se> writes:
> + [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...]
Why not just --strict?
> @@ -10,16 +10,18 @@
> #include "pkt-line.h"
> #include "cache.h"
>
> -static int log_syslog;
> +static int log_syslog = 0;
I'd drop this.
> /* If this is set, git-daemon-export-ok is not required */
> static int export_all_trees = 0;
>
> @@ -81,69 +83,49 @@ static void loginfo(const char *err, ...
> va_end(params);
> }
>
> -static int path_ok(const char *dir)
> +static const char *path_ok(const char *dir)
> {
> + const char *path = is_git_repo(dir, strict_paths);
> + /* No such directory or not a git archive */
> + if(!path) {
> + logerror("'%s': unable to chdir or not a git archive", dir);
> + return NULL;
> }
>
> if ( ok_paths && *ok_paths ) {
> + char **pp = NULL;
> + int dirlen = strlen(path);
>
> for ( pp = ok_paths ; *pp ; pp++ ) {
> int len = strlen(*pp);
> + if ( len <= dirlen && !strncmp(*pp, path, len) ) {
> + if( path[len] == '\0' || (!strict_paths && path[len] == '/') )
> + return path;
> }
> }
Sorry, but I am a bit confused. Does this mean that you need to
list all directories under --strict-paths, instead of saying
"/pub/scm and everything under it is OK"?
I like the general direction this set is taking, but let's let
it simmer for a while.
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Chris Shoemaker @ 2005-11-02 0:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Petr Baudis, Kay Sievers, git
In-Reply-To: <46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com>
On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
> On 11/2/05, Petr Baudis <pasky@suse.cz> wrote:
> > What about having the color indicate the number of affected files (let's
> > say on a blue..red scale) and the width the size of patch?
>
> I'm a /little bit/ colour blind on the red scale -- so I vote for 2
> bars, each half the heigth of the current bar. ;-)
I was going to use two bars for add vs. delete, but this could work,
too. I'm intending on getting back to this ASAP, but for now my
cvsimport problems are higher priority (see other post).
-chris
>
> martin
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Petr Baudis @ 2005-11-01 23:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Chris Shoemaker, Kay Sievers, git
In-Reply-To: <46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com>
Dear diary, on Wed, Nov 02, 2005 at 12:33:38AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> On 11/2/05, Petr Baudis <pasky@suse.cz> wrote:
> > What about having the color indicate the number of affected files (let's
> > say on a blue..red scale) and the width the size of patch?
>
> I'm a /little bit/ colour blind on the red scale -- so I vote for 2
> bars, each half the heigth of the current bar. ;-)
That's certainly possible as well (if you make each of the bars of
different color), but for most people not equally visually obvious.
Perhaps we could have a knob at the bottom of the page, but that isn't
very satisfying a solution either... :-(
Another possibility is to make the height dynamic and in proportion with
the number of affected files. Or combine both the color and dynamic
height. I believe changing the color to red would make it appear as
black for the red-color-blind people?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: git-pull - strange (copy/rename) messages ?!
From: Daniel Barkalow @ 2005-11-01 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0ew6jf3.fsf@assigned-by-dhcp.cox.net>
On Tue, 1 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I think it's more confusing for the system to report Z differently from
> > other things, because there's nothing special about what it found, except
> > that Z happens to be last.
>
> What would we get for a simple "mv A B and nothing else" case if
> we follow your proposal and Pasky's? What about "cp A B and
> nothing else" case?
My suggestion for "mv A B" would be:
Rename A
=> B (n%)
Same as the current thing, except with a line break and indentation before
the arrow.
For "cp A B":
Copy A
=> B (n%)
I think the only difference should be the line with "A" on it, and the
difference should only depend on whether A still exists.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-pull - strange (copy/rename) messages ?!
From: Petr Baudis @ 2005-11-01 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vu0ew6jf3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Nov 02, 2005 at 12:24:32AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I think it's more confusing for the system to report Z differently from
> > other things, because there's nothing special about what it found, except
> > that Z happens to be last.
>
> What would we get for a simple "mv A B and nothing else" case if
> we follow your proposal and Pasky's? What about "cp A B and
> nothing else" case?
In case of my proposal, you get the mv and cp as usual, since there are
no multiple rename candidates for A.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ 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