* Re: [PATCH 1/1] Tried to fix git-svn's handling of filenames with embedded '@'.
From: Junio C Hamano @ 2006-05-28 20:42 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Seth Falcon
In-Reply-To: <m2verqkobr.fsf@ziti.fhcrc.org>
Seth Falcon <sethfalcon@gmail.com> writes:
> svn has trouble parsing files with embedded '@' characters. For
> example,
>
> svn propget svn:keywords foo@bar.c
> svn: Syntax error parsing revision 'bar.c'
>
> I asked about this on #svn and the workaround suggested was to append
> an explicit revision specifier:
>
> svn propget svn:keywords foo@bar.c@BASE
>
> This patch appends '@BASE' to the filename in all calls to 'svn
> propget'.
Eric, this sounds sane to me. Ack?
^ permalink raw reply
* Re: git-format-patch question
From: Junio C Hamano @ 2006-05-28 20:35 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2odxikktm.fsf@ziti.fhcrc.org>
Seth Falcon <sethfalcon@gmail.com> writes:
> 1. When is one supposed to use --signoff? I gather the answer is
> project specific, but a statement of what's expected for git
> itself would probably help clarify things for me.
You shouldn't ;-). Rather, you should sign-off when you make a
commit, or if you are forwarding somebody else's patch, before
you send the e-mail off.
> 2. How should I add extra notes to an email generated using
> git-format-patch? Is this in the docs somewhere that I missed? Is
> there a recommended way to do this?
Read the format-patch output in your e-mail buffer and edit just
like you edit any text you write in your e-mail.
^ permalink raw reply
* git-format-patch question
From: Seth Falcon @ 2006-05-28 19:31 UTC (permalink / raw)
To: git
Hi,
A few questions about git-format-patch:
1. When is one supposed to use --signoff? I gather the answer is
project specific, but a statement of what's expected for git
itself would probably help clarify things for me.
2. How should I add extra notes to an email generated using
git-format-patch? Is this in the docs somewhere that I missed? Is
there a recommended way to do this?
3. Is signoff broken? I get:
$ git-format-patch --stdout --signoff master
fatal: unrecognized argument: --signoff
When I pass -s instead of --signoff, I get output, but no patch and
no signoff looking thing. Without --signoff and without -s, I get
reasonable looking output.
Thanks,
+ seth
^ permalink raw reply
* [PATCH] git-write-tree writes garbage on sparc64
From: Dennis Stosberg @ 2006-05-28 19:08 UTC (permalink / raw)
To: git
In the "next" branch, write_index_ext_header() writes garbage on a
64-bit big-endian machine; the written index file will be unreadable.
I noticed this on NetBSD/sparc64. Reproducible with:
$ git init-db
$ :>file
$ git-update-index --add file
$ git-write-tree
$ git-update-index
error: index uses extension, which we do not understand
fatal: index file corrupt
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
read-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 36bd4ea..c499c51 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -826,7 +826,7 @@ static int ce_write(SHA_CTX *context, in
}
static int write_index_ext_header(SHA_CTX *context, int fd,
- unsigned long ext, unsigned long sz)
+ unsigned int ext, unsigned int sz)
{
ext = htonl(ext);
sz = htonl(sz);
--
1.3.3.g3c38f
^ permalink raw reply related
* Fix memory leak in "git rev-list --objects"
From: Linus Torvalds @ 2006-05-28 18:37 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Martin Langhoff
Martin Langhoff points out that "git repack -a" ends up using up a lot of
memory for big archives, and that git cvsimport probably should do only
incremental repacks in order to avoid having repacking flush all the
caches.
The big majority of the memory usage of repacking is from git rev-list
tracking all objects, and this patch should go a long way in avoiding the
excessive memory usage: the bulk of it was due to the object names being
leaked from the tree parser.
For the historic Linux kernel archive, this simple patch does:
Before:
/usr/bin/time git-rev-list --all --objects > /dev/null
72.45user 0.82system 1:13.55elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+125376minor)pagefaults 0swaps
After:
/usr/bin/time git-rev-list --all --objects > /dev/null
75.22user 0.48system 1:16.34elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+43921minor)pagefaults 0swaps
where we do end up wasting a bit of time on some extra strdup()s (which
could be avoided, but that would require tracking where the pathnames came
from), but we avoid a lot of memory usage.
Minor page faults track maximum RSS very closely (each page fault maps in
one page into memory), so the reduction from 125376 page faults to 43921
means a rough reduction of VM footprint from almost half a gigabyte to
about a third of that. Those numbers were also double-checked by looking
at "top" while the process was running.
(Side note: at least part of the remaining VM footprint is the mapping of
the 177MB pack-file, so the remaining memory use is at least partly "well
behaved" from a project caching perspective).
For the current git archive itself, the memory usage for a "--all
--objects" rev-list invocation dropped from 7128 pages to 2318 (27MB to
9MB), so the reduction seems to hold for much smaller projects too.
For regular "git-rev-list" usage (ie without the "--objects" flag) this
patch has no impact.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index f11dbd6..5277d3c 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -103,6 +103,7 @@ static struct object_list **process_blob
if (obj->flags & (UNINTERESTING | SEEN))
return p;
obj->flags |= SEEN;
+ name = strdup(name);
return add_object(obj, p, path, name);
}
@@ -122,6 +123,7 @@ static struct object_list **process_tree
if (parse_tree(tree) < 0)
die("bad tree object %s", sha1_to_hex(obj->sha1));
obj->flags |= SEEN;
+ name = strdup(name);
p = add_object(obj, p, path, name);
me.up = path;
me.elem = name;
@@ -134,6 +136,7 @@ static struct object_list **process_tree
p = process_tree(entry->item.tree, p, &me, entry->name);
else
p = process_blob(entry->item.blob, p, &me, entry->name);
+ free(entry->name);
free(entry);
entry = next;
}
^ permalink raw reply related
* Re: Remote git-cat-file?
From: Jakub Narebski @ 2006-05-28 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <7vu07acanv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> It would be nice I think to be able to have remote alternatives,...
>
> Yup, I think I've mentioned that one as one of "the mostly
> unimplementable but would be very nice to have crazy wishlist
> items" some time ago. What people would want is not a "shallow"
> clone, but a "lazy" clone, and in the ideal world that would
> obviously be a nice thing to have.
I think that it should be only "commit-lazy", i.e. downloading whole trees,
subtrees, and objects pointed by tags, only not following the parent links
of commits; perhaps also other links to commits (branches, tags, tag
objects).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH 1/1] Tried to fix git-svn's handling of filenames with embedded '@'.
From: Seth Falcon @ 2006-05-28 18:15 UTC (permalink / raw)
To: git
In-Reply-To: <m21wuem2xj.fsf@ziti.fhcrc.org>
svn has trouble parsing files with embedded '@' characters. For
example,
svn propget svn:keywords foo@bar.c
svn: Syntax error parsing revision 'bar.c'
I asked about this on #svn and the workaround suggested was to append
an explicit revision specifier:
svn propget svn:keywords foo@bar.c@BASE
This patch appends '@BASE' to the filename in all calls to 'svn
propget'.
---
contrib/git-svn/git-svn.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index b3e0684..498ffe0 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -336,7 +336,7 @@ sub show_ignore {
my %ign;
File::Find::find({wanted=>sub{if(lstat $_ && -d _ && -d "$_/.svn"){
s#^\./##;
- @{$ign{$_}} = safe_qx(qw(svn propget svn:ignore),$_);
+ @{$ign{$_}} = safe_qx(qw(svn propget svn:ignore),$_ . "\@BASE");
}}, no_chdir=>1},'.');
print "\n# /\n";
@@ -860,7 +860,7 @@ sub sys { system(@_) == 0 or croak $? }
sub eol_cp {
my ($from, $to) = @_;
- my $es = safe_qx(qw/svn propget svn:eol-style/, $to);
+ my $es = safe_qx(qw/svn propget svn:eol-style/, $to . "\@BASE");
open my $rfd, '<', $from or croak $!;
binmode $rfd or croak $!;
open my $wfd, '>', $to or croak $!;
@@ -898,7 +898,8 @@ sub do_update_index {
while (my $x = <$p>) {
chomp $x;
if (!$no_text_base && lstat $x && ! -l _ &&
- safe_qx(qw/svn propget svn:keywords/,$x)) {
+ safe_qx(qw/svn propget svn:keywords/,
+ $x . "\@BASE")) {
my $mode = -x _ ? 0755 : 0644;
my ($v,$d,$f) = File::Spec->splitpath($x);
my $tb = File::Spec->catfile($d, '.svn', 'tmp',
--
1.3.3.gb931
^ permalink raw reply related
* Re: [PATCH] new environment variable GIT_TEMPLATE_DIR to override default template
From: Matthias Lederhofer @ 2006-05-28 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pzadpfr.fsf@assigned-by-dhcp.cox.net>
> I like the part to let git-clone pass --template down to git-init-db,
> but once it is in place I doubt you would still need GIT_TEMPLATE_DIR.
> I'd rather not to introduce new environment variables if we can
> avoid them.
I like the variable because it makes it very easy to change the
default template directory (so I don't have to remember passing
--template every time I clone or create a new repository). But
aliases/default options (~/.git/config thread) this would make this
possible too.
> Here, $template is either empty string "", or "--template=dir"
> after argument parsing. But then it does this:
>
> > @@ -203,7 +206,7 @@ trap 'err=$?; cd ..; rm -r "$D"; exit $e
> > case "$bare" in
> > yes) GIT_DIR="$D" ;;
> > *) GIT_DIR="$D/.git" ;;
> > -esac && export GIT_DIR && git-init-db || usage
> > +esac && export GIT_DIR && git-init-db "$template" || usage
>
> which I suspect would make git-init-db barf if you did not pass
> any --template=foo option to git-clone. Did you test your patch?
Sorry, I did not run make test and did not test it without the option.
Shall I send a new patch?
^ permalink raw reply
* [PATCH 0/1] Tried to fix git-svn's handling of filenames with embedded '@'.
From: Seth Falcon @ 2006-05-28 18:15 UTC (permalink / raw)
To: git
Hi Eric, all,
I decided to give git-svn a try for a large svn project and during my
first git-svn fetch operation, I'm seeing a failure that seems related
to recent changes in the handling of svn keywords.
Here is the traceback:
svn: Syntax error parsing revision '.R'
256 at /home/sfalcon/util/scm/bin/git-svn line 1124
main::safe_qx('svn', 'propget', 'svn:keywords', 'Biobase/inst/Code/R/get@PKGNAME@.R') called at /home/sfalcon/util/scm/bin/git-svn line 900
main::do_update_index('ARRAY(0x8395840)', 'add', 'undef')
called at /home/sfalcon/util/scm/bin/git-svn line 926
Unfortunately, my project has a file named "get@PKGNAME@.R" and svn
thinks the '@.R' part is specifying a revision. Here comes a patch
that got me going again. Not sure it is the right fix, nor whether it
covers all places where some action will be needed.
Best,
+ seth
^ permalink raw reply
* Re: Remote git-cat-file?
From: Junio C Hamano @ 2006-05-28 17:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5c3c5$i47$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> It would be nice I think to be able to have remote alternatives,...
Yup, I think I've mentioned that one as one of "the mostly
unimplementable but would be very nice to have crazy wishlist
items" some time ago. What people would want is not a "shallow"
clone, but a "lazy" clone, and in the ideal world that would
obviously be a nice thing to have.
^ permalink raw reply
* Re: [PATCH] new environment variable GIT_TEMPLATE_DIR to override default template
From: Junio C Hamano @ 2006-05-28 17:33 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1Fk3yR-0006Gd-36@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> directory and --template=<template_directory> option for to git-clone
>
> ---
>> Please document such changes, in the spirit of
>
> That's right, here are both patches in one because the second patch
> would also change the documentation of the first one.
Thanks.
* Please don't put the beginning of one sentence on Subject
line and start the body of the message with the rest of that
sentence. Instead, come up with a short (meaning "fits on
the Subject line without wrapping with 80-column terminal")
title that describes what the patch does -- it is a good
sanity check to make sure your patch is doing one thing and
one thing only, instead of mixing unrelated mess together.
* Please sign-off your patch.
* Please test your patch for existing usage, not just for the
new usage you added, to avoid regressions.
I like the part to let git-clone pass --template down to git-init-db,
but once it is in place I doubt you would still need GIT_TEMPLATE_DIR.
I'd rather not to introduce new environment variables if we can
avoid them.
> diff --git a/git-clone.sh b/git-clone.sh
> index d96894d..1c7ae12 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -102,6 +102,7 @@ quiet=
> local=no
> use_local=no
> local_shared=no
> +template=
> no_checkout=
> upload_pack=
> bare=
> @@ -120,6 +121,8 @@ while
> *,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
> *,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
> local_shared=yes; use_local=yes ;;
> + *,--template=*)
> + template="$1" ;;
> *,-q|*,--quiet) quiet=-q ;;
> *,--use-separate-remote)
> use_separate_remote=t ;;
Here, $template is either empty string "", or "--template=dir"
after argument parsing. But then it does this:
> @@ -203,7 +206,7 @@ trap 'err=$?; cd ..; rm -r "$D"; exit $e
> case "$bare" in
> yes) GIT_DIR="$D" ;;
> *) GIT_DIR="$D/.git" ;;
> -esac && export GIT_DIR && git-init-db || usage
> +esac && export GIT_DIR && git-init-db "$template" || usage
which I suspect would make git-init-db barf if you did not pass
any --template=foo option to git-clone. Did you test your patch?
So I'd do it like this instead.
-- >8 --
[PATCH] Let git-clone to pass --template=dir option to git-init-db.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-clone.txt | 9 +++++++--
git-clone.sh | 10 ++++++++--
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b333f51..94d9393 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -9,8 +9,8 @@ git-clone - Clones a repository
SYNOPSIS
--------
[verse]
-'git-clone' [-l [-s]] [-q] [-n] [--bare] [-o <name>] [-u <upload-pack>]
- [--reference <repository>]
+'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
+ [-o <name>] [-u <upload-pack>] [--reference <repository>]
<repository> [<directory>]
DESCRIPTION
@@ -89,6 +89,11 @@ OPTIONS
the command to specify non-default path for the command
run on the other end.
+--template=<template_directory>::
+ Specify the directory from which templates will be used;
+ if unset the templates are taken from the installation
+ defined default, typically `/usr/share/git-core/templates`.
+
<repository>::
The (possibly remote) repository to clone from. It can
be any URL git-fetch supports.
diff --git a/git-clone.sh b/git-clone.sh
index d96894d..de59904 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@ # See git-sh-setup why.
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--template=<template_directory>] [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -102,6 +102,7 @@ quiet=
local=no
use_local=no
local_shared=no
+unset template
no_checkout=
upload_pack=
bare=
@@ -120,6 +121,11 @@ while
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
+ 1,--template) usage ;;
+ *,--template)
+ shift; template="--template=$1" ;;
+ *,--template=*)
+ template="$1" ;;
*,-q|*,--quiet) quiet=-q ;;
*,--use-separate-remote)
use_separate_remote=t ;;
@@ -203,7 +209,7 @@ trap 'err=$?; cd ..; rm -r "$D"; exit $e
case "$bare" in
yes) GIT_DIR="$D" ;;
*) GIT_DIR="$D/.git" ;;
-esac && export GIT_DIR && git-init-db || usage
+esac && export GIT_DIR && git-init-db ${template+"$template"} || usage
case "$bare" in
yes)
GIT_DIR="$D" ;;
--
1.3.3.g2a0a
^ permalink raw reply related
* Re: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Christopher Faylor @ 2006-05-28 16:39 UTC (permalink / raw)
To: Zakirov, Salikh, git
In-Reply-To: <E124AAE027DA384D8B919F93E4D8C70801EFFB52@mssmsx402nb>
On Sun, May 28, 2006 at 12:57:35AM +0400, Zakirov, Salikh wrote:
>Junio C Hamano <junkio@cox.net> writes:
>> So even in this modern day, preserving CRLF is not
>> something that happens by default -- you would need to make sure
>> that everybody on your mailpath to the recipient is set up the
>> right way.
>
>> So now I am less in favor of the change than when I wrote that
>> response.
>
>I understand this reasoning, and I am not sure if the fix is correct
>from the "GIT world" point of view.
>
>However, I believe that the command sequence git-format-patch, git-am
>without any e-mail transfer in between and in the same repository
>should work perfectly regardless of the contents of the files,
>no matter if they are binary, text, or "CRLF text" or even
>"broken LF and CRLF text". This is a requirement from a nasty "real
>world".
>
>Junio, could you point at a right place to fix to get git-format-patch,
>git-am sequence work flawlessly on Cygwin?
>
>By the way, the change affects only non-Unix users, as fopen(..., "rt")
>is equivalent to fopen(..., "rb") on all Unixes anyway.
But fopen(..., "r") is not equivalent to fopen(..., "rb") on Cygwin.
Wouldn't you want to add the "b" there to be assured of a binary open?
cgf
^ permalink raw reply
* Re: Remote git-cat-file?
From: Jakub Narebski @ 2006-05-28 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20060528T124835-757@post.gmane.org>
Elrond wrote:
> Linus Torvalds <torvalds <at> osdl.org> writes:
>>
>> Just out of interest, why would you ever want to just look at a single
>> object?
[...]
>
> The other possible use for remote git-cat-file:
> It might be useful in shallow repos to selectively load objects "on demand".
> (In fact, I screwed my repo by trying to make it shallow.)
It would be nice I think to be able to have remote alternatives, loading
(downloading and saving) objects "on demand" ("lazy alternatives"). Not necessary
only with "shallow repo"/"shallow clone".
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Remote git-cat-file?
From: Elrond @ 2006-05-28 10:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605271727110.5623@g5.osdl.org>
Linus Torvalds <torvalds <at> osdl.org> writes:
[...]
> But in the general case, the answer is no. Set up a gitweb thing, and look
> up the objects that way. Or just pull the repo, and look at it locally.
I ended up doing that (clone whole remote repo).
> Just out of interest, why would you ever want to just look at a single
> object?
Well...
I screwed up my local clone of a repo. git-fsck told me what objects I needed.
So I finally ended up downloading the whole repo again to extract 16 objects. ;)
The other possible use for remote git-cat-file:
It might be useful in shallow repos to selectively load objects "on demand".
(In fact, I screwed my repo by trying to make it shallow.)
Elrond
^ permalink raw reply
* [gitweb/patch] commit log bodies should be pre-format tagged
From: Paul Jakma @ 2006-05-28 10:28 UTC (permalink / raw)
To: kay.sievers; +Cc: git list
[-- Attachment #1: Type: TEXT/PLAIN, Size: 697 bytes --]
Hi Kay,
I don't know about you, but when I write commit messages, I don't
HTML format them. ;)
Attached patch wraps commit log messages in HTML pre tags. Without
this patch, any commits with any kind of ASCII-formatted structure
look strange at best (e.g. traditional GNUish ChangeLog style which
use indentation), and unintelligble at worst (ASCII art or
diagrammes).
The log, commit and commitdiff pages all still validate, and the RSS
feed looks /much/ better in Liferea. Probably it could be done in
some smarter way with divs and CSS though, but hey.
Please apply. :)
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Fiber optics caused gas main leak
[-- Attachment #2: Type: TEXT/PLAIN, Size: 3734 bytes --]
--- gitweb.cgi.orig 2006-05-28 10:30:38.000000000 +0100
+++ gitweb.cgi 2006-05-28 11:12:52.000000000 +0100
@@ -1218,12 +1218,12 @@
}
print "</table>\n\n" .
"</div>\n";
- print "<div class=\"page_body\">";
+ print "<div class=\"page_body\"><pre>";
my $comment = $tag{'comment'};
foreach my $line (@$comment) {
- print esc_html($line) . "<br/>\n";
+ print esc_html($line) . "\n";
}
- print "</div>\n";
+ print "</pre></div>\n";
git_footer_html();
}
@@ -1547,22 +1547,22 @@
"<link>" . esc_html("$my_url?p=$project;a=commit;h=$commit") . "</link>\n" .
"<description>" . esc_html($co{'title'}) . "</description>\n" .
"<content:encoded>" .
- "<![CDATA[\n";
+ "<![CDATA[<pre>\n";
my $comment = $co{'comment'};
foreach my $line (@$comment) {
$line = decode("utf8", $line, Encode::FB_DEFAULT);
- print "$line<br/>\n";
+ print "$line\n";
}
- print "<br/>\n";
+ print "\n";
foreach my $line (@difftree) {
if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
next;
}
my $file = validate_input(unquote($7));
$file = decode("utf8", $file, Encode::FB_DEFAULT);
- print "$file<br/>\n";
+ print "$file\n";
}
- print "]]>\n" .
+ print "</pre>]]>\n" .
"</content:encoded>\n" .
"</item>\n";
}
@@ -1673,7 +1673,7 @@
"</div>\n" .
"<i>" . esc_html($co{'author_name'}) . " [$ad{'rfc2822'}]</i><br/>\n" .
"</div>\n" .
- "<div class=\"log_body\">\n";
+ "<div class=\"log_body\"><pre>\n";
my $comment = $co{'comment'};
my $empty = 0;
foreach my $line (@$comment) {
@@ -1688,12 +1688,12 @@
} else {
$empty = 0;
}
- print format_log_line_html($line) . "<br/>\n";
+ print format_log_line_html($line) . "\n";
}
if (!$empty) {
- print "<br/>\n";
+ print "\n";
}
- print "</div>\n";
+ print "</pre></div>\n";
}
git_footer_html();
}
@@ -1783,7 +1783,7 @@
}
print "</table>".
"</div>\n";
- print "<div class=\"page_body\">\n";
+ print "<div class=\"page_body\"><pre>\n";
my $comment = $co{'comment'};
my $empty = 0;
my $signed = 0;
@@ -1799,13 +1799,13 @@
}
if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
$signed = 1;
- print "<span style=\"color: #888888\">" . esc_html($line) . "</span><br/>\n";
+ print "</pre><span style=\"color: #888888\">" . esc_html($line) . "</span><br/><pre>\n";
} else {
$signed = 0;
- print format_log_line_html($line) . "<br/>\n";
+ print format_log_line_html($line) . "\n";
}
}
- print "</div>\n";
+ print "</pre></div>\n";
print "<div class=\"list_head\">\n";
if ($#difftree > 10) {
print(($#difftree + 1) . " files changed:\n");
@@ -1982,7 +1982,7 @@
print "<div>\n" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$hash"), -class => "title"}, esc_html($co{'title'}) . $ref) . "\n" .
"</div>\n";
- print "<div class=\"page_body\">\n";
+ print "<div class=\"page_body\"><pre>\n";
my $comment = $co{'comment'};
my $empty = 0;
my $signed = 0;
@@ -2004,9 +2004,9 @@
} else {
$empty = 0;
}
- print format_log_line_html($line) . "<br/>\n";
+ print format_log_line_html($line) . "\n";
}
- print "<br/>\n";
+ print "</pre><br/>\n";
foreach my $line (@difftree) {
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
# ':100644 100644 7f9281985086971d3877aca27704f2aaf9c448ce bc190ebc71bbd923f2b728e505408f5e54bd073a M rev-tree.c'
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Johannes Schindelin @ 2006-05-28 10:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Jeff Garzik, Git Mailing List, Linux Kernel
In-Reply-To: <Pine.LNX.4.64.0605270905190.5623@g5.osdl.org>
Hi,
On Sat, 27 May 2006, Linus Torvalds wrote:
> Well, git-stripspace actually does something slightly differently, in that
> it also removes extraneous all-whitespace lines from the beginning, the
> end, and the middle (in the middle, the rule is: two or more empty lines
> are collapsed into one).
>
> Ie it's a total hack for parsing just commit messages (and it is in C,
> because I can personally write 25 lines of C in about a millionth of the
> time I can write 3 lines of perl).
But there is no good reason not to add some code and a command line
switch, so that this tool with a very generic name actually performs what
a normal person would expect from that name.
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Johannes Schindelin @ 2006-05-28 9:57 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550605270212n267661rd0463a301cbe1b95@mail.gmail.com>
Hi,
On Sat, 27 May 2006, Marco Costalba wrote:
> [...patch that fixes late-night-hackery...]
Acked-By: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Keith Owens @ 2006-05-28 8:33 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Jeff Garzik, Git Mailing List, Linux Kernel
In-Reply-To: <Pine.LNX.4.61.0605271441080.4857@yvahk01.tjqt.qr>
Jan Engelhardt (on Sat, 27 May 2006 14:42:02 +0200 (MEST)) wrote:
>And the CL form is
> perl -i -pe '...'
>Somehow, you can't group it to -ipe, but who cares.
-i takes an optional extension which is used to optionally create
backup files. As such, -i must be followed by space if you want no
extension (and no backup).
^ permalink raw reply
* Re: Remote git-cat-file?
From: Linus Torvalds @ 2006-05-28 0:32 UTC (permalink / raw)
To: Elrond; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605271727110.5623@g5.osdl.org>
On Sat, 27 May 2006, Linus Torvalds wrote:
>
> Well, depending on just how much you know about the object, you can fake
> it. For example, if you already know it's a commit, and you know the
> parents, then yes, you can download it by basically saying that you want
> that particular object and you already have the parents.
The other (similar) case is for tag objects. When you do "git ls-remote"
on the remote repo, it will tell you both the tag object SHA and the
object SHA of the thing it points to, so you can then do a git protocol
exchange where you do a
for_each_tag
"want <tagsha1>"
for_each_tag
"have <objectitpointstosha1>"
and you'll get just the tag object back.
Linus
^ permalink raw reply
* Re: Remote git-cat-file?
From: Linus Torvalds @ 2006-05-28 0:29 UTC (permalink / raw)
To: Elrond; +Cc: git
In-Reply-To: <loom.20060528T002420-957@post.gmane.org>
On Sat, 27 May 2006, Elrond wrote:
>
> Is it possible via the git: protocol to do a git-cat-file?
>
> To download just one object by its ID?
Nope.
Well, depending on just how much you know about the object, you can fake
it. For example, if you already know it's a commit, and you know the
parents, then yes, you can download it by basically saying that you want
that particular object and you already have the parents.
But in the general case, the answer is no. Set up a gitweb thing, and look
up the objects that way. Or just pull the repo, and look at it locally.
Just out of interest, why would you ever want to just look at a single
object?
Linus
^ permalink raw reply
* Remote git-cat-file?
From: Elrond @ 2006-05-27 22:26 UTC (permalink / raw)
To: git
Hi,
Is it possible via the git: protocol to do a git-cat-file?
To download just one object by its ID?
Thanks for your help.
Elrond
^ permalink raw reply
* RE: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Zakirov, Salikh @ 2006-05-27 20:57 UTC (permalink / raw)
To: git
Junio C Hamano <junkio@cox.net> writes:
> So even in this modern day, preserving CRLF is not
> something that happens by default -- you would need to make sure
> that everybody on your mailpath to the recipient is set up the
> right way.
> So now I am less in favor of the change than when I wrote that
> response.
I understand this reasoning, and I am not sure if the fix is correct
from the "GIT world" point of view.
However, I believe that the command sequence git-format-patch, git-am
without any e-mail transfer in between and in the same repository
should work perfectly regardless of the contents of the files,
no matter if they are binary, text, or "CRLF text" or even
"broken LF and CRLF text". This is a requirement from a nasty "real
world".
Junio, could you point at a right place to fix to get git-format-patch,
git-am sequence work flawlessly on Cygwin?
By the way, the change affects only non-Unix users, as fopen(..., "rt")
is equivalent to fopen(..., "rb") on all Unixes anyway.
^ permalink raw reply
* Fix "--abbrev=xyz" for revision listing
From: Linus Torvalds @ 2006-05-27 19:24 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
The revision argument parsing was happily parsing "--abbrev", but it
didn't parse "--abbrev=<n>".
Which was hidden by the fact that the diff options _would_ parse
--abbrev=<n>, so it would actually silently parse it, it just
wouldn't use it for the same things that a plain "--abbrev" was
used for.
Which seems a bit insane.
With this patch, if you do "git log --abbrev=10" it will abbreviate the
merge parent commit ID's to ten hex characters, which was probably what
you expected.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/revision.c b/revision.c
index 2294b16..42c077a 100644
--- a/revision.c
+++ b/revision.c
@@ -733,6 +733,14 @@ int setup_revisions(int argc, const char
revs->abbrev = DEFAULT_ABBREV;
continue;
}
+ if (!strncmp(arg, "--abbrev=", 9)) {
+ revs->abbrev = strtoul(arg + 9, NULL, 10);
+ if (revs->abbrev < MINIMUM_ABBREV)
+ revs->abbrev = MINIMUM_ABBREV;
+ else if (revs->abbrev > 40)
+ revs->abbrev = 40;
+ continue;
+ }
if (!strcmp(arg, "--abbrev-commit")) {
revs->abbrev_commit = 1;
continue;
^ permalink raw reply related
* Re: [PATCH 2/3] Document current cvsps limitations.
From: Yann Dirson @ 2006-05-27 19:13 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163933.474.4059.stgit@gandelf.nowhere.earth>
Well, you will have corrected by yourself, but I did mean
"cvsexportcommit limitations" :)
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH] new environment variable GIT_TEMPLATE_DIR to override default template
From: Matthias Lederhofer @ 2006-05-27 18:57 UTC (permalink / raw)
To: git
In-Reply-To: <20060527132554.GC10488@pasky.or.cz>
directory and --template=<template_directory> option for to git-clone
---
> Please document such changes, in the spirit of
That's right, here are both patches in one because the second patch
would also change the documentation of the first one.
---
ac3c3fdd2423d2184306af3e6e93397475953284
Documentation/git-clone.txt | 10 ++++++++--
Documentation/git-init-db.txt | 2 ++
builtin-init-db.c | 3 +++
git-clone.sh | 7 +++++--
4 files changed, 18 insertions(+), 4 deletions(-)
ac3c3fdd2423d2184306af3e6e93397475953284
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b333f51..8e833aa 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -9,8 +9,8 @@ git-clone - Clones a repository
SYNOPSIS
--------
[verse]
-'git-clone' [-l [-s]] [-q] [-n] [--bare] [-o <name>] [-u <upload-pack>]
- [--reference <repository>]
+'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
+ [-o <name>] [-u <upload-pack>] [--reference <repository>]
<repository> [<directory>]
DESCRIPTION
@@ -34,6 +34,12 @@ branch you are currently working on. Re
OPTIONS
-------
+--template=<template_directory>::
+ Provide the directory from which templates will be used.
+ The default template directory is `/usr/share/git-core/templates`.
+ You can override the default template directory with the
+ `$GIT_TEMPLATE_DIR` environment variable.
+
--local::
-l::
When the repository to clone from is on a local machine,
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 8a150d8..273f394 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -16,6 +16,8 @@ OPTIONS
--template=<template_directory>::
Provide the directory from which templates will be used.
The default template directory is `/usr/share/git-core/templates`.
+ You can override the default template directory with the
+ `$GIT_TEMPLATE_DIR` environment variable.
--shared::
Specify that the git repository is to be shared amongst several users.
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 2a1384c..cf5bd39 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -253,6 +253,9 @@ int cmd_init_db(int argc, const char **a
die(init_db_usage);
}
+ if (!template_dir)
+ template_dir = getenv("GIT_TEMPLATE_DIR");
+
/*
* Set up the default .git directory contents
*/
diff --git a/git-clone.sh b/git-clone.sh
index d96894d..1c7ae12 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@ # See git-sh-setup why.
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--template=<template_directory>] [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -102,6 +102,7 @@ quiet=
local=no
use_local=no
local_shared=no
+template=
no_checkout=
upload_pack=
bare=
@@ -120,6 +121,8 @@ while
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
+ *,--template=*)
+ template="$1" ;;
*,-q|*,--quiet) quiet=-q ;;
*,--use-separate-remote)
use_separate_remote=t ;;
@@ -203,7 +206,7 @@ trap 'err=$?; cd ..; rm -r "$D"; exit $e
case "$bare" in
yes) GIT_DIR="$D" ;;
*) GIT_DIR="$D/.git" ;;
-esac && export GIT_DIR && git-init-db || usage
+esac && export GIT_DIR && git-init-db "$template" || usage
case "$bare" in
yes)
GIT_DIR="$D" ;;
--
1.3.3.g40505
^ permalink raw reply related
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