* cg-commit does not run pre-commit hook?
From: Wolfgang Denk @ 2006-10-11 20:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Hi,
I noticed that cg-commit does not run the pre-commit hook. Is this
intentional, or am I doing anyhting wrong? When I use git-coimmit
instead the hook is run just fine. This is with git-1.4.2.1 and
cogito-0.18 of FC4 / FC5 systems.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are bugs and then there are bugs. And then there are bugs.
- Karl Lehenbauer
^ permalink raw reply
* [PATCH] gitweb: Do not automatically append " git" to custom site name
From: Petr Baudis @ 2006-10-11 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If you customized the site name, you probably do not want the " git"
appended so that the page title is not bastardized; I want repo.or.cz pages
titled "Public Git Hosting", not "Public Git Hosting git" (what's hosting
what?).
This slightly changes the $site_name semantics but only very
insignificantly.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c2dfdab..d165fdc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -39,7 +39,7 @@ our $home_link_str = "++GITWEB_HOME_LINK
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
-our $site_name = "++GITWEB_SITENAME++" || $ENV{'SERVER_NAME'} || "Untitled";
+our $site_name = "++GITWEB_SITENAME++" || "$ENV{'SERVER_NAME'} Git" || "Untitled Git";
# filename of html text to include at top of each page
our $site_header = "++GITWEB_SITE_HEADER++";
@@ -1455,7 +1455,7 @@ sub git_header_html {
my $status = shift || "200 OK";
my $expires = shift;
- my $title = "$site_name git";
+ my $title = "$site_name";
if (defined $project) {
$title .= " - $project";
if (defined $action) {
@@ -3842,7 +3842,7 @@ sub git_opml {
<?xml version="1.0" encoding="utf-8"?>
<opml version="1.0">
<head>
- <title>$site_name Git OPML Export</title>
+ <title>$site_name OPML Export</title>
</head>
<body>
<outline text="git RSS feeds">
^ permalink raw reply related
* [PATCH] gitweb: Restore object-named links in item lists
From: Petr Baudis @ 2006-10-11 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This restores the redundant links removed earlier. It supersedes my patch
to stick slashes to tree entries.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 42 ++++++++++++++++++++++++++++--------------
1 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a11fa38..d8298b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1785,18 +1785,20 @@ sub git_print_tree_entry {
file_name=>"$basedir$t->{'name'}", %base_key),
-class => "list"}, esc_html($t->{'name'})) . "</td>\n";
print "<td class=\"link\">";
+ print $cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "blob");
if ($have_blame) {
- print $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
+ print " | " .
+ $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
file_name=>"$basedir$t->{'name'}", %base_key)},
- "blame");
+ "blame");
}
if (defined $hash_base) {
- if ($have_blame) {
- print " | ";
- }
- print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+ print " | " .
+ $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
hash=>$t->{'hash'}, file_name=>"$basedir$t->{'name'}")},
- "history");
+ "history");
}
print " | " .
$cgi->a({-href => href(action=>"blob_plain", hash_base=>$hash_base,
@@ -1811,17 +1813,19 @@ sub git_print_tree_entry {
esc_html($t->{'name'}));
print "</td>\n";
print "<td class=\"link\">";
+ print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "tree");
if (defined $hash_base) {
- print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+ print " | " .
+ $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
file_name=>"$basedir$t->{'name'}")},
- "history");
- if ($have_snapshot) {
- print " | ";
- }
+ "history");
}
if ($have_snapshot) {
- print $cgi->a({-href => href(action=>"snapshot", hash=>$t->{'hash'})},
- "snapshot");
+ print " | " .
+ $cgi->a({-href => href(action=>"snapshot", hash=>$t->{'hash'})},
+ "snapshot");
}
print "</td>\n";
}
@@ -1902,6 +1906,9 @@ sub git_difftree_body {
print $cgi->a({-href => "#patch$patchno"}, "patch");
print " | ";
}
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
+ hash_base=>$parent, file_name=>$diff{'file'})},
+ "blob") . " | ";
print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
file_name=>$diff{'file'})},
"blame") . " | ";
@@ -1947,6 +1954,9 @@ sub git_difftree_body {
}
print " | ";
}
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
+ hash_base=>$hash, file_name=>$diff{'file'})},
+ "blob") . " | ";
print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
file_name=>$diff{'file'})},
"blame") . " | ";
@@ -1987,6 +1997,9 @@ sub git_difftree_body {
}
print " | ";
}
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
+ hash_base=>$parent, file_name=>$diff{'from_file'})},
+ "blob") . " | ";
print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
file_name=>$diff{'from_file'})},
"blame") . " | ";
@@ -2154,6 +2167,7 @@ sub git_shortlog_body {
href(action=>"commit", hash=>$commit), $ref);
print "</td>\n" .
"<td class=\"link\">" .
+ $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
$cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
if (gitweb_have_snapshot()) {
^ permalink raw reply related
* Re: [PATCH] gitweb: Show project README if available
From: Junio C Hamano @ 2006-10-11 19:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Jeff King
In-Reply-To: <egje5k$5rn$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Jeff King wrote:
>
>> On Wed, Oct 11, 2006 at 02:23:00PM +0200, Jakub Narebski wrote:
>>
>>> Can any Perl expert tell us how Perl truly solve this? What is the best
>>> way to dump whole [remaining] contents of file (from filehandle) to STDOUT?
>>
>> The same you would in C: read fix-sized buffers and dump them.
> [...]
>> Or you can use the File::Copy module, which is part of the standard
>> distribution (and I believe has been so for all perl5 versions, but I
>> could be wrong):
>
> And
>
> {
> local $/;
> print <$fd>;
> }
>
> doesn't do the right thing?
Jakub, you asked for "the best way" not "any way that would
produce a correct result". Your 4-liner is shorter in the
source but it risks slurping a 10 megabyte file into memory
first, only to discard it after immediately writing it out.
You can strace your Perl to see what yours does yourself:
strace perl -e 'print <STDIN>' >/dev/null <some-huge-file
You will see a bunch of read(0, ..., 4096) and after all of that
finishes, finally you will see a bunch of write(1, ..., 4096).
Where do you think the data is in the meantime?
Jeff gave you better ways that do not have that problem.
^ permalink raw reply
* [PATCH] git-svn: multi-init saves and reuses --tags and --branches arguments
From: Eric Wong @ 2006-10-11 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
This should make it much easier to track newly added tags and
branches. Re-running multi-init without command-line arguments
should now detect new-tags and branches.
--trunk shouldn't change often, but running multi-init on it
is now idempotent.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index f5c7d46..5a6c87e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -682,12 +682,17 @@ sub multi_init {
}
$_trunk = $url . $_trunk;
}
+ my $ch_id;
if ($GIT_SVN eq 'git-svn') {
- print "GIT_SVN_ID set to 'trunk' for $_trunk\n";
+ $ch_id = 1;
$GIT_SVN = $ENV{GIT_SVN_ID} = 'trunk';
}
init_vars();
- init($_trunk);
+ unless (-d $GIT_SVN_DIR) {
+ print "GIT_SVN_ID set to 'trunk' for $_trunk\n" if $ch_id;
+ init($_trunk);
+ sys('git-repo-config', 'svn.trunk', $_trunk);
+ }
complete_url_ls_init($url, $_branches, '--branches/-b', '');
complete_url_ls_init($url, $_tags, '--tags/-t', 'tags/');
}
@@ -937,16 +942,21 @@ sub complete_url_ls_init {
print STDERR "W: Unrecognized URL: $u\n";
die "This should never happen\n";
}
+ # don't try to init already existing refs
my $id = $pfx.$1;
- print "init $u => $id\n";
$GIT_SVN = $ENV{GIT_SVN_ID} = $id;
init_vars();
- init($u);
+ unless (-d $GIT_SVN_DIR) {
+ print "init $u => $id\n";
+ init($u);
+ }
}
exit 0;
}
waitpid $pid, 0;
croak $? if $?;
+ my ($n) = ($switch =~ /^--(\w+)/);
+ sys('git-repo-config', "svn.$n", $var);
}
sub common_prefix {
--
1.4.2.3.gc5a8
^ permalink raw reply related
* [PATCH] git-svn: log command fixes
From: Eric Wong @ 2006-10-11 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11605928022833-git-send-email-normalperson@yhbt.net>
Change the --verbose flag to more closely match svn. I was
somehow under the impression that --summary included --raw diff
output, but I was wrong. We now pass -r --raw --name-status as
arguments if passed -v/--verbose.
-r (recursive) is passed by default, since users usually want
it, and accepting it causes difficulty with the -r<revision>
option used by svn users. A --non-recursive switch has been
added to disable this.
Of course, --summary, --raw, -p and any other git-log options
can still be passed directly (without --name-status).
Also, several warnings about referencing undefined variables
have been fixed.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 32 +++++++++++++++++++++++++-------
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 5a6c87e..4f6e6a3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -52,7 +52,7 @@ my ($_revision,$_stdin,$_no_ignore_ext,$
$_template, $_shared, $_no_default_regex, $_no_graft_copy,
$_limit, $_verbose, $_incremental, $_oneline, $_l_fmt, $_show_commit,
$_version, $_upgrade, $_authors, $_branch_all_refs, @_opt_m,
- $_merge, $_strategy, $_dry_run, $_ignore_nodate);
+ $_merge, $_strategy, $_dry_run, $_ignore_nodate, $_non_recursive);
my (@_branch_from, %tree_map, %users, %rusers, %equiv);
my ($_svn_co_url_revs, $_svn_pg_peg_revs);
my @repo_path_split_cache;
@@ -114,6 +114,7 @@ my %cmd = (
'incremental' => \$_incremental,
'oneline' => \$_oneline,
'show-commit' => \$_show_commit,
+ 'non-recursive' => \$_non_recursive,
'authors-file|A=s' => \$_authors,
} ],
'commit-diff' => [ \&commit_diff, 'Commit a diff between two trees',
@@ -752,13 +753,18 @@ sub show_log {
# ignore
} elsif (/^:\d{6} \d{6} $sha1_short/o) {
push @{$c->{raw}}, $_;
+ } elsif (/^[ACRMDT]\t/) {
+ # we could add $SVN_PATH here, but that requires
+ # remote access at the moment (repo_path_split)...
+ s#^([ACRMDT])\t# $1 #;
+ push @{$c->{changed}}, $_;
} elsif (/^diff /) {
$d = 1;
push @{$c->{diff}}, $_;
} elsif ($d) {
push @{$c->{diff}}, $_;
} elsif (/^ (git-svn-id:.+)$/) {
- (undef, $c->{r}, undef) = extract_metadata($1);
+ ($c->{url}, $c->{r}, undef) = extract_metadata($1);
} elsif (s/^ //) {
push @{$c->{l}}, $_;
}
@@ -850,7 +856,8 @@ sub git_svn_log_cmd {
my ($r_min, $r_max) = @_;
my @cmd = (qw/git-log --abbrev-commit --pretty=raw
--default/, "refs/remotes/$GIT_SVN");
- push @cmd, '--summary' if $_verbose;
+ push @cmd, '-r' unless $_non_recursive;
+ push @cmd, qw/--raw --name-status/ if $_verbose;
return @cmd unless defined $r_max;
if ($r_max == $r_min) {
push @cmd, '--max-count=1';
@@ -861,7 +868,7 @@ sub git_svn_log_cmd {
my ($c_min, $c_max);
$c_max = revdb_get($REVDB, $r_max);
$c_min = revdb_get($REVDB, $r_min);
- if ($c_min && $c_max) {
+ if (defined $c_min && defined $c_max) {
if ($r_max > $r_max) {
push @cmd, "$c_min..$c_max";
} else {
@@ -2561,6 +2568,12 @@ sub show_commit {
}
}
+sub show_commit_changed_paths {
+ my ($c) = @_;
+ return unless $c->{changed};
+ print "Changed paths:\n", @{$c->{changed}};
+}
+
sub show_commit_normal {
my ($c) = @_;
print '-' x72, "\nr$c->{r} | ";
@@ -2570,7 +2583,8 @@ sub show_commit_normal {
my $nr_line = 0;
if (my $l = $c->{l}) {
- while ($l->[$#$l] eq "\n" && $l->[($#$l - 1)] eq "\n") {
+ while ($l->[$#$l] eq "\n" && $#$l > 0
+ && $l->[($#$l - 1)] eq "\n") {
pop @$l;
}
$nr_line = scalar @$l;
@@ -2582,11 +2596,15 @@ sub show_commit_normal {
} else {
$nr_line .= ' lines';
}
- print $nr_line, "\n\n";
+ print $nr_line, "\n";
+ show_commit_changed_paths($c);
+ print "\n";
print $_ foreach @$l;
}
} else {
- print "1 line\n\n";
+ print "1 line\n";
+ show_commit_changed_paths($c);
+ print "\n";
}
foreach my $x (qw/raw diff/) {
--
1.4.2.3.gc5a8
^ permalink raw reply related
* Re: [PATCH] gitweb: Show project README if available
From: Jakub Narebski @ 2006-10-11 18:46 UTC (permalink / raw)
To: git
In-Reply-To: <20061011181729.GB2897@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 11, 2006 at 02:23:00PM +0200, Jakub Narebski wrote:
>
>> Can any Perl expert tell us how Perl truly solve this? What is the best
>> way to dump whole [remaining] contents of file (from filehandle) to STDOUT?
>
> The same you would in C: read fix-sized buffers and dump them.
[...]
> Or you can use the File::Copy module, which is part of the standard
> distribution (and I believe has been so for all perl5 versions, but I
> could be wrong):
And
{
local $/;
print <$fd>;
}
doesn't do the right thing?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Jeff King @ 2006-10-11 18:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, git
In-Reply-To: <200610111423.00656.jnareb@gmail.com>
On Wed, Oct 11, 2006 at 02:23:00PM +0200, Jakub Narebski wrote:
> Can any Perl expert tell us how Perl truly solve this? What is the best
> way to dump whole [remaining] contents of file (from filehandle) to STDOUT?
The same you would in C: read fix-sized buffers and dump them. Reading
the whole file obviously has unbounded memory allocation. Reading lines
requires unnecessary parsing and may have unbounded memory allocation
(though in practice for text files I doubt either is a big deal).
You can loop like this:
while(1) {
my $r = read(STDIN, my $buf, 4096);
defined($r) or die "error: $!";
$r or last;
print STDOUT $buf;
}
Or you can use the File::Copy module, which is part of the standard
distribution (and I believe has been so for all perl5 versions, but I
could be wrong):
use File::Copy qw(copy);
copy(STDIN, STDOUT);
-Peff
^ permalink raw reply
* Re: Gitweb indentation wrong in Internet Explorer
From: Ralf Baechle @ 2006-10-11 18:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egjang$nmh$1@sea.gmane.org>
On Wed, Oct 11, 2006 at 07:47:24PM +0200, Jakub Narebski wrote:
> >> When I use it (and I believe I've seen this on my laptop as well as my
> >> workstation) all left-hand margin whitespace is collapsed to nothingness.
> >> Once can still parse the code, but it's harder with no indentations.
> >
> > A screenshot from a Windows laptop to illustrate the problem is at
> > http://www.linux-mips.org/~ralf/gitweb.png. It shows the code was
> > preformatted correctly which seems to be an IE bug but the following patch
> > seems to work around it.
>
> Which version of gitweb? We have removed s/ / /g; in esc_html
> subroutine in favor of using "white-space: pre;" in CSS some time ago,
> and we have added escaping FORM FEED and ESCAPE characters.
Anything since since at least June 19 seems affected, including yesterday's
version.
> Could you send git patches, by the way? Or at least '-p' diffs?
Nope. I'm just forwarding this.
Ralf
^ permalink raw reply
* Re: [RFC] separate .git from working directory
From: Martin Waitz @ 2006-10-11 18:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0610110623q365d3ffcw9ba9e11936d03a9d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
hoi :)
On Wed, Oct 11, 2006 at 08:23:50PM +0700, Nguyen Thai Ngoc Duy wrote:
> I was thinking about this while reading subproject thread. In a simple
> case, I have a repo A located at ~/project-a and another repo B
> located at ~/project-a/some/dir/project-b. With this setup, command
> "find" and other directory-recursive commands will run horribly from
> ~/project-a when they go inside project-b/.git (no I don't want to
> repack -d everytime I want to find something).
no it won't.
For subprojects you really need a shared object repository.
In such a setup b/.git/objects would be a symlink to the parent
object directory.
On the other hand, you already have the same problem with
a/.git/objects. If you really want to move .git outside of the
working directory you can always do so by using a symlink for
the entire .git directory.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Gitweb indentation wrong in Internet Explorer
From: Luben Tuikov @ 2006-10-11 18:13 UTC (permalink / raw)
To: Ralf Baechle, git
In-Reply-To: <20061011172553.GA1147@linux-mips.org>
--- Ralf Baechle <ralf@linux-mips.org> wrote:
> I have a report from an MSIE suffering user:
>
> > When I use it (and I believe I've seen this on my laptop as well as my
> > workstation) all left-hand margin whitespace is collapsed to nothingness.
> > Once can still parse the code, but it's harder with no indentations.
>
> A screenshot from a Windows laptop to illustrate the problem is at
> http://www.linux-mips.org/~ralf/gitweb.png. It shows the code was
> preformatted correctly which seems to be an IE bug but the following patch
> seems to work around it.
Thank you.
Has anyone let MSIE people know about this bug? Or tried latest MSIE?
Luben
>
> *** gitweb.cgi.dist 2006-10-09 19:02:19.561726255 +0100
> --- gitweb.cgi 2006-10-09 19:03:31.744837495 +0100
> ***************
> *** 234,239 ****
> --- 234,240 ----
> my $str = shift;
> $str = decode("utf8", $str, Encode::FB_DEFAULT);
> $str = escapeHTML($str);
> + $str =~ s/ / /g;
> return $str;
> }
>
> Thanks,
>
> Ralf
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: core-git and porcelains
From: Robin Rosenberg @ 2006-10-11 18:08 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <egivn8$5mf$1@sea.gmane.org>
onsdag 11 oktober 2006 16:39 skrev Pazu:
[...]
> For the larger part of my day, however, I'm looking into using git as a
> personal tool in a very large corporate project; This project is
> currently controlled using subversion, and my idea is to use git as a
> 'staging' system, where I work (possibly offline) before pushing changes
> to the upstream (remote, slow as hell) subversion repository. Here,
> git-svn seems to be my best friend.
I work against a CVS repo in the way you want to use SVN and I find StGIT
to be a perfect fit for my needs. StGIT's doesn't replace GIT's command so I
use StGIT for it's patch management and the standard git commands for the
rest. I can't see that working agains SVN should be any different, except
the git-svn* vs git-cvs commands.
The GIT commands aren't that hard to understand. The difficulty is to know
which commands to use. I use these commands
stg init, new, add, remove push, pop, refresh, status, pull, goto, diff (and a
new command float that I wrote which simplified some pop-push sequences)
git log push, diff
In addition I use qgit for browsing when git log isn't comfortable enough and
occasionally the standard patch command.
-- robin
^ permalink raw reply
* Re: Clueless bisect error message
From: Jeff King @ 2006-10-11 18:04 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <m3ejtfvwvi.fsf@defiant.localdomain>
On Wed, Oct 11, 2006 at 02:51:29PM +0200, Krzysztof Halasa wrote:
> > + die "You can't bisect a seeked tree!"
> Just to make sure: dictionary.reference.com doesn't know the
> "seeked" word (I don't either though that may be normal).
>
> Should it read "sought"? Not sure what does the message talk about.
Seeked is not a "real" word in the sense of being in any dictionary. The
past participle form of "seek" is indeed "sought" (though one might want
to use the passive perfect participle form "being sought" for this
case).
However, the use of the word "sought" implies to me the classical
definition of the word seek: "to look for something." The definition we
are using here is a more modern, computer-oriented definition: "to move
to a position within an ordered set" (since we are referring to Cogito's
cg-seek command). Just as you might verbify (another non-word!) a
command and say "I catted those files together", the tree has been
"seeked." One could argue it should be "cat'd" and "seek'd" to indicate
their non-word status, but that idiom is common enough among
programmers, especially Unix users, that I suspect it will make sense
either way.
At any rate, the word "seeked" was in the original error message, so I
didn't introduce it. Are other people bothered by it?
-Peff
^ permalink raw reply
* Re: Gitweb indentation wrong in Internet Explorer
From: Jakub Narebski @ 2006-10-11 17:47 UTC (permalink / raw)
To: git
In-Reply-To: <20061011172553.GA1147@linux-mips.org>
Ralf Baechle wrote:
> I have a report from an MSIE suffering user:
>
>> When I use it (and I believe I've seen this on my laptop as well as my
>> workstation) all left-hand margin whitespace is collapsed to nothingness.
>> Once can still parse the code, but it's harder with no indentations.
>
> A screenshot from a Windows laptop to illustrate the problem is at
> http://www.linux-mips.org/~ralf/gitweb.png. It shows the code was
> preformatted correctly which seems to be an IE bug but the following patch
> seems to work around it.
Which version of gitweb? We have removed s/ / /g; in esc_html
subroutine in favor of using "white-space: pre;" in CSS some time ago,
and we have added escaping FORM FEED and ESCAPE characters.
Could you send git patches, by the way? Or at least '-p' diffs?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn fetch fails when a file is renamed changing only case
From: Eric Wong @ 2006-10-11 17:42 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <ege016$vrb$1@sea.gmane.org>
Pazu <pazu@pazu.com.br> wrote:
> For example, if you had a file named TestFile and it's renamed to
> TESTFILE, git-svn fails to fetch revisions after the rename.
>
> My perl skills are close to non-existant, so I'm afraid I don't know how
> to fix this. Attached to this message, however, is a sample svn
> repository that can reproduce this bug. Just unpack it somewhere (let's
> say, in /tmp) and try the following:
>
> tar -C /tmp -xzf git-svn-rename-test.tar.gz
> mkdir test-wc
> cd test-wc
> git-svn init file:///tmp/git-svn-rename-test
> git-svn fetch
>
> The last command will fail after fetching revision #3, where a file
> named TestFile was renamed to TESTFILE. Here's the stack trace:
>
> svn: 'TestFile' is not under version control
> 256 at /Users/pazu/bin/git-svn line 2015
> main::safe_qx('svn', 'propget', 'svn:keywords',
> 'TestFile@BASE') called at /Users/pazu/bin/git-svn line 2154
> main::svn_propget_base('svn:keywords', 'TestFile') called at
> /Users/pazu/bin/git-svn line 1773
> main::do_update_index('ARRAY(0x180bd68)', 'remove', 'undef')
> called at /Users/pazu/bin/git-svn line 1805
> main::index_changes() called at /Users/pazu/bin/git-svn line 1875
> main::git_commit('HASH(0x180bd98)',
> 'c77db38dc752305ba19ebe19b22306551d0f8d52') called at
> /Users/pazu/bin/git-svn line 346
> main::fetch_cmd() called at /Users/pazu/bin/git-svn line 290
> main::fetch() called at /Users/pazu/bin/git-svn line 149
> I'm on Mac OS X (Intel) 10.4.8
Ah, the problem is that git-svn relies on git-diff-files and
git-ls-files to track changes when using the command-line svn client.
git itself is a case-sensitive file-system, but git-svn relies on the
working tree if you didn't have the SVN libraries, and successfully
stats the 'TestFile' even though it no longer exists (and is replaced
by 'TESTFILE').
Good to know that the SVN:: libraries are working for you, though.
--
Eric Wong
^ permalink raw reply
* Gitweb indentation wrong in Internet Explorer
From: Ralf Baechle @ 2006-10-11 17:25 UTC (permalink / raw)
To: git
I have a report from an MSIE suffering user:
> When I use it (and I believe I've seen this on my laptop as well as my
> workstation) all left-hand margin whitespace is collapsed to nothingness.
> Once can still parse the code, but it's harder with no indentations.
A screenshot from a Windows laptop to illustrate the problem is at
http://www.linux-mips.org/~ralf/gitweb.png. It shows the code was
preformatted correctly which seems to be an IE bug but the following patch
seems to work around it.
*** gitweb.cgi.dist 2006-10-09 19:02:19.561726255 +0100
--- gitweb.cgi 2006-10-09 19:03:31.744837495 +0100
***************
*** 234,239 ****
--- 234,240 ----
my $str = shift;
$str = decode("utf8", $str, Encode::FB_DEFAULT);
$str = escapeHTML($str);
+ $str =~ s/ / /g;
return $str;
}
Thanks,
Ralf
^ permalink raw reply
* Re: core-git and porcelains
From: Pazu @ 2006-10-11 17:13 UTC (permalink / raw)
To: git
In-Reply-To: <20061011165403.GC31298@spearce.org>
Shawn Pearce wrote:
> I don't use multiple upstream branches in SVN fortunately, but the
> git-svn documentation suggests there is a way to change the Git
> branch name from 'refs/remotes/git-svn' to another name such that
> you can create one Git branch for each remote SVN branch. Of course
> you need to set that environment variable before invoking git-svn.
I was reading git-svn documentation and just found about multi-init.
Seems like you're describing, execept that no branch get init'ed as the
"default" branch, and you always need to specify the the branch name
before doing a fetch/dcomic/etc. I hope this works for me -- I'll need
to switch between two or three remote branches quite frequently.
> As for my daily work with git-svn, I run "git svn fetch" to fetch any
> changes that had occurred in SVN along the branch I follow, then if
> any changes did exist I merge them into my Git working branch with
> "git pull . refs/remotes/git-svn". When I'm ready to send stuff
> back up to SVN I do "git svn dcommit refs/remotes/git-svn..master",
> where master is the name of the Git branch I want to send.
Sounds a lot like what I do today with svk. If git works for me just as
good as svk, the speed increase alone will make the switch worth.
-- Marcus
^ permalink raw reply
* Re: core-git and porcelains
From: Seth Falcon @ 2006-10-11 17:01 UTC (permalink / raw)
To: git
In-Reply-To: <20061011150842.GA31298@spearce.org>
I second Shawn's suggestion to stick with core Git. I have similar
uses as you describe: projects where I'm the lone developer and using
git to help track projects that use svn.
+ seth
^ permalink raw reply
* Re: core-git and porcelains
From: Shawn Pearce @ 2006-10-11 16:54 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <egj73t$80e$1@sea.gmane.org>
Pazu <pazu@pazu.com.br> wrote:
> Shawn Pearce wrote:
>
> >I would just stick with core Git. I haven't used Cogito in almost
> >a year so I can't say what I'm missing there, but core Git works
> >very well for all of my needs. I use it in a lot of different
> >projects, some which require git-svn, others which require some
> >bastard git-svn-workalike for non-SVN systems, and others which
> >are just Git projects and don't have to cooperate with others.
>
> Thanks for the advice, Shawn. Would you mind expanding on how you work
> with git-svn, however? Specially, how's your everyday work, and how do
> you deal with multiple upstream branches.
I don't use multiple upstream branches in SVN fortunately, but the
git-svn documentation suggests there is a way to change the Git
branch name from 'refs/remotes/git-svn' to another name such that
you can create one Git branch for each remote SVN branch. Of course
you need to set that environment variable before invoking git-svn.
As for my daily work with git-svn, I run "git svn fetch" to fetch any
changes that had occurred in SVN along the branch I follow, then if
any changes did exist I merge them into my Git working branch with
"git pull . refs/remotes/git-svn". When I'm ready to send stuff
back up to SVN I do "git svn dcommit refs/remotes/git-svn..master",
where master is the name of the Git branch I want to send.
--
Shawn.
^ permalink raw reply
* Re: core-git and porcelains
From: Pazu @ 2006-10-11 16:45 UTC (permalink / raw)
To: git
In-Reply-To: <20061011150842.GA31298@spearce.org>
Shawn Pearce wrote:
> I would just stick with core Git. I haven't used Cogito in almost
> a year so I can't say what I'm missing there, but core Git works
> very well for all of my needs. I use it in a lot of different
> projects, some which require git-svn, others which require some
> bastard git-svn-workalike for non-SVN systems, and others which
> are just Git projects and don't have to cooperate with others.
Thanks for the advice, Shawn. Would you mind expanding on how you work
with git-svn, however? Specially, how's your everyday work, and how do
you deal with multiple upstream branches.
-- Marcus
^ permalink raw reply
* [PATCH] atomic write for sideband remote messages
From: Nicolas Pitre @ 2006-10-11 15:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
It has been a few times that I ended up with such a confusing display:
|remote: Generating pack...
|remote: Done counting 17 objects.
|remote: Result has 9 objects.
|remote: Deltifying 9 objects.
|remote: 100% (9/9) done
|remote: Unpacking 9 objects
|Total 9, written 9 (delta 8), reused 0 (delta 0)
| 100% (9/9) done
The confusion can be avoided in most cases by writing the remote message
in one go to prevent interleacing with local messages. The buffer
declaration has been moved inside recv_sideband() to avoid extra string
copies.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-archive.c b/builtin-archive.c
index 6dabdee..9177379 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -75,7 +75,7 @@ static int run_remote_archiver(const cha
die("git-archive: expected a flush");
/* Now, start reading from fd[0] and spit it out to stdout */
- rv = recv_sideband("archive", fd[0], 1, 2, buf, sizeof(buf));
+ rv = recv_sideband("archive", fd[0], 1, 2);
close(fd[0]);
rv |= finish_connect(pid);
diff --git a/fetch-clone.c b/fetch-clone.c
index b632ca0..76b99af 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -115,12 +115,10 @@ static pid_t setup_sideband(int sideband
die("%s: unable to fork off sideband demultiplexer", me);
if (!side_pid) {
/* subprocess */
- char buf[LARGE_PACKET_MAX];
-
close(fd[0]);
if (xd[0] != xd[1])
close(xd[1]);
- if (recv_sideband(me, xd[0], fd[1], 2, buf, sizeof(buf)))
+ if (recv_sideband(me, xd[0], fd[1], 2))
exit(1);
exit(0);
}
diff --git a/sideband.c b/sideband.c
index 1b14ff8..277fa3c 100644
--- a/sideband.c
+++ b/sideband.c
@@ -11,10 +11,13 @@ #include "sideband.h"
* stream, aka "verbose"). A message over band #3 is a signal that
* the remote died unexpectedly. A flush() concludes the stream.
*/
-int recv_sideband(const char *me, int in_stream, int out, int err, char *buf, int bufsz)
+int recv_sideband(const char *me, int in_stream, int out, int err)
{
+ char buf[7 + LARGE_PACKET_MAX + 1];
+ strcpy(buf, "remote:");
while (1) {
- int len = packet_read_line(in_stream, buf, bufsz);
+ int band, len;
+ len = packet_read_line(in_stream, buf+7, LARGE_PACKET_MAX);
if (len == 0)
break;
if (len < 1) {
@@ -22,25 +25,26 @@ int recv_sideband(const char *me, int in
safe_write(err, buf, len);
return SIDEBAND_PROTOCOL_ERROR;
}
+ band = buf[7] & 0xff;
len--;
- switch (buf[0] & 0xFF) {
+ switch (band) {
case 3:
- safe_write(err, "remote: ", 8);
- safe_write(err, buf+1, len);
- safe_write(err, "\n", 1);
+ buf[7] = ' ';
+ buf[8+len] = '\n';
+ safe_write(err, buf, 8+len+1);
return SIDEBAND_REMOTE_ERROR;
case 2:
- safe_write(err, "remote: ", 8);
- safe_write(err, buf+1, len);
+ buf[7] = ' ';
+ safe_write(err, buf, 8+len);
continue;
case 1:
- safe_write(out, buf+1, len);
+ safe_write(out, buf+8, len);
continue;
default:
- len = sprintf(buf + 1,
+ len = sprintf(buf,
"%s: protocol error: bad band #%d\n",
- me, buf[0] & 0xFF);
- safe_write(err, buf+1, len);
+ me, band);
+ safe_write(err, buf, len);
return SIDEBAND_PROTOCOL_ERROR;
}
}
diff --git a/sideband.h b/sideband.h
index 4872106..a84b691 100644
--- a/sideband.h
+++ b/sideband.h
@@ -7,7 +7,7 @@ #define SIDEBAND_REMOTE_ERROR -1
#define DEFAULT_PACKET_MAX 1000
#define LARGE_PACKET_MAX 65520
-int recv_sideband(const char *me, int in_stream, int out, int err, char *, int);
+int recv_sideband(const char *me, int in_stream, int out, int err);
ssize_t send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);
#endif
^ permalink raw reply related
* Re: [RFC] separate .git from working directory
From: Sean @ 2006-10-11 15:43 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0610110623q365d3ffcw9ba9e11936d03a9d@mail.gmail.com>
On Wed, 11 Oct 2006 20:23:50 +0700
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
> I was thinking about this while reading subproject thread. In a simple
> case, I have a repo A located at ~/project-a and another repo B
> located at ~/project-a/some/dir/project-b. With this setup, command
> "find" and other directory-recursive commands will run horribly from
> ~/project-a when they go inside project-b/.git (no I don't want to
> repack -d everytime I want to find something).
> I propose to move project-b/.git outside and place a file, say
> .gitdir, in project-b directory. git-sh-setup and setup_git_directory
> are taught to recognize .gitdir, read it to find the actual GIT_DIR
> recorded inside .gitdir. This way git commands inside project-b should
> work fine while I can "find ~/project-a -name blah" or "grep -R blah"
> quickly.
> .gitdir format could be a simple shell-like format with environment
> variable assignments.
Probably wouldn't be too hard to implement, but is it worth it?
You can export a GIT_DIR manually pretty easily if you want to move
the .git directory somewhere else. Also you could make a "git find"
shell script named "gf" that does something like:
#/bin/sh
find "$@" ! -path '*/.git/*'
Which would let you type "gf -name blah" and automatically ignore
the .git directory.
Sean
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Andreas Ericsson @ 2006-10-11 15:35 UTC (permalink / raw)
To: ltuikov; +Cc: Jakub Narebski, git
In-Reply-To: <20061010191904.99261.qmail@web31809.mail.mud.yahoo.com>
Luben Tuikov wrote:
>
> The question is: Given the average engineer, what is the gitweb interface
> such that they can start using it fastest with the minimum amount of
> questions?
>
Originally, the question was about average gitweb users. I'm sorry
Luben, but as long as you propagate links that are not
a) blue
b) underlined
I'll have to disagree with everything you say out of pure principle.
>
> The golden question:
> What is the interface such that both git-experts and never-seen-git-
> but-know-about-SCMs engineers can find it intuitive to use with minimal
> amount of questions?
>
Just make links blue and underlined and people will click them out of
curiousity. 100% guaranteed. Try to spoonfeed engineers and they will
spit on you, because engineers like to figure things out, even if
they're obvious. Try to make things intuitive for average users and you
will be wrong, because intuition is highly culture- and experience
oriented. Try to make it foolproof and you will fail, because fools are
so ingenious.
The one and only thing everyone looking at a gitweb interface has in
common is curiousity, so appeal to that rather than trying any of the
doomed paths above.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-10-11 15:09 UTC (permalink / raw)
To: git
In-Reply-To: <egdge3$t12$1@sea.gmane.org>
Jakub Narebski wrote:
> * Graph of number of changed files in given branch; probably should be
> cached.
See for example StatCVS and FishEye
http://www-128.ibm.com/developerworks/java/library/j-statcvs/
http://statcvs.sourceforge.net/statcvs-stats/
http://fisheye.codehaus.org/browse/activecluster
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Release 1.4.2 build failure
From: Phillip Susi @ 2006-10-11 15:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejtfzur8.fsf@assigned-by-dhcp.cox.net>
Yes, I think the debian build system does that. I must have missed the
newer 1.4.2.x releases when scanning the directory. Thanks.
Junio C Hamano wrote:
> Are you by any chance running the test with the stdin connected
> to </dev/null?
>
> If so, the fix is in 1.4.2.2.
>
> BTW, the latest "maint" release is 1.4.2.3 and we have 1.4.3-rc2
> from the "master" branch.
>
^ 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