* [PATCH 2/6] gitweb: Add mod_perl version string to "generator" meta header
From: Jakub Narebski @ 2006-12-27 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Add mod_perl version string (the value of $ENV{'MOD_PERL'} if it is
set) to "generator" meta header.
The purpose of this is to identify version of gitweb, now that
codepath may differ for gitweb run as CGI script, run under
mod_perl 1.0 and run under mod_perl 2.0.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
For example mod_perl 2.0 sets MOD_PERL to something like
"mod_perl/2.0.1".
This patch was created because further patches make gitweb to
have different codepath for mod_perl; so mod_perl version string
was added to "generator" meta header in HTML header.
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index aaee217..bb1d66c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1724,6 +1724,8 @@ sub git_header_html {
-charset => 'utf-8',
-status => $status,
-expires => $expires);
+ # the environmental variable MOD_PERL has 'mod_perl/VERSION' value if set
+ my $mod_perl_version = $ENV{'MOD_PERL'} ? " $ENV{'MOD_PERL'}" : '';
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -1732,7 +1734,7 @@ sub git_header_html {
<!-- git core binaries version $git_version -->
<head>
<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
-<meta name="generator" content="gitweb/$version git/$git_version"/>
+<meta name="generator" content="gitweb/$version git/$git_version$mod_perl_version"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
--
1.4.4.3
^ permalink raw reply related
* [PATCH 3/6] gitweb: Precompile CGI routines for mod_perl
From: Jakub Narebski @ 2006-12-27 23:00 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Following advice from CGI(3pm) man page, precompile all CGI routines
for mod_perl, in the BEGIN block.
If you want to compile without importing use the compile() method
instead:
use CGI();
CGI->compile();
This is particularly useful in a mod_perl environment, in which you
might want to precompile all CGI routines in a startup script, and then
import the functions individually in each mod_perl script.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Could help. I'm a bit unsure.
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bb1d66c..3888563 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -18,6 +18,10 @@ use File::Find qw();
use File::Basename qw(basename);
binmode STDOUT, ':utf8';
+BEGIN {
+ CGI->compile() if $ENV{MOD_PERL};
+}
+
our $cgi = new CGI;
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
--
1.4.4.3
^ permalink raw reply related
* [PATCH 1/6] gitweb: Separate HTTP header output
From: Jakub Narebski @ 2006-12-27 22:57 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Separate output (writing) of HTTP headers into http_header subroutine,
to centralize setting HTTP header for further mod_perl specific tweaks
(to be able to run gitweb without PerlOptions +ParseHeaders, which
would speed gitweb some), and checking for HEAD request.
Always return just after HTTP header is sent when asking only about
headers (HTTP request method 'HEAD'); first appeared in git_rss.
While at it uniquify style of http_header(...) calls, formerly
"print $cgi->header(...)", and remove default HTTP status, '200 OK'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This one is fairly generic, and if considered worthy, I think
can be accepted without much ado.
Perhaps the cleanup part of it should be split into separate patch?
gitweb/gitweb.perl | 40 +++++++++++++++++++++++++++-------------
1 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 65fcdb0..aaee217 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1678,7 +1678,17 @@ sub blob_mimetype {
}
## ======================================================================
-## functions printing HTML: header, footer, error page
+## functions printing HTTP or HTML: header, footer, error page
+
+sub http_header {
+ my @header = @_;
+
+ print $cgi->header(@header);
+
+ # Optimization: skip generating the body if client asks only
+ # for HTTP header (e.g. cache validation).
+ return if ($cgi->request_method() eq 'HEAD');
+}
sub git_header_html {
my $status = shift || "200 OK";
@@ -1709,8 +1719,11 @@ sub git_header_html {
} else {
$content_type = 'text/html';
}
- print $cgi->header(-type=>$content_type, -charset => 'utf-8',
- -status=> $status, -expires => $expires);
+ http_header(
+ -type => $content_type,
+ -charset => 'utf-8',
+ -status => $status,
+ -expires => $expires);
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -2983,7 +2996,7 @@ sub git_forks {
sub git_project_index {
my @projects = git_get_projects_list($project);
- print $cgi->header(
+ http_header(
-type => 'text/plain',
-charset => 'utf-8',
-content_disposition => 'inline; filename="index.aux"');
@@ -3375,7 +3388,7 @@ sub git_blob_plain {
$save_as .= '.txt';
}
- print $cgi->header(
+ http_header(
-type => "$type",
-expires=>$expires,
-content_disposition => 'inline; filename="' . "$save_as" . '"');
@@ -3591,10 +3604,9 @@ sub git_snapshot {
my $filename = basename($project) . "-$hash.tar.$suffix";
- print $cgi->header(
+ http_header(
-type => "application/$ctype",
- -content_disposition => 'inline; filename="' . "$filename" . '"',
- -status => '200 OK');
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
my $git = git_cmd_str();
my $name = $project;
@@ -3979,7 +3991,7 @@ sub git_blobdiff {
}
} elsif ($format eq 'plain') {
- print $cgi->header(
+ http_header(
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
@@ -4128,7 +4140,7 @@ sub git_commitdiff {
my $tagname = git_get_rev_name_tags($hash);
my $filename = basename($project) . "-$hash.patch";
- print $cgi->header(
+ http_header(
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
@@ -4465,12 +4477,12 @@ sub git_feed {
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
%latest_date = parse_date($latest_commit{'author_epoch'});
- print $cgi->header(
+ http_header(
-type => $content_type,
-charset => 'utf-8',
-last_modified => $latest_date{'rfc2822'});
} else {
- print $cgi->header(
+ http_header(
-type => $content_type,
-charset => 'utf-8');
}
@@ -4670,7 +4682,9 @@ sub git_atom {
sub git_opml {
my @list = git_get_projects_list();
- print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
+ http_header(
+ -type => 'text/xml',
+ -charset => 'utf-8');
print <<XML;
<?xml version="1.0" encoding="utf-8"?>
<opml version="1.0">
--
1.4.4.3
^ permalink raw reply related
* [PATCH 0/6] gitweb: Some mod_perl specific support (but not only)
From: Jakub Narebski @ 2006-12-27 22:55 UTC (permalink / raw)
To: git
This is series of gitweb patches to provide better mod_perl
support, for now running gitweb under mod_perl's Registry,
but in the future as mod_perl handler.
First patch is mod_perl related only in a way that it provides
path to mod_perl specific support, but has its own advantages
even when running gitweb simply as CGI script, namely the
centralization of stopping output after HTTP header for HEAD
requests. Till this patch only git_feed had this feature (originally
by Andreas Fuchs).
Second patch was created because further patches make gitweb to
have different codepath for mod_perl; so mod_perl version string
was added to "generator" meta header in HTML header.
I'm not so sure about third patch, namely if I understood what
is written in CGI(3pm) about compile method.
Fourth patch prepares the way for mod_perl specific support.
Perhaps "our $r = shift @_;" instead of "my $r = shift @_;"
would be better.
Fifth patch appears to be unnecessary, at least for now, because
mod_perl Registry populates %ENV hash (and does not need to set
envirionmental variables). Still, it prepares the way for future
running gitweb as mod_perl handler, and not under Registry.
Sixth patch is an RFC. It tries to add HTTP headers directly,
allowing Apache to not need to parse headers, which should speed
up gitweb a bit. It also makes use of mod_perl meets_expectation
method to respond to If-Modified-Since: and If-None-Match: requests
for cache validation. Current state is a bit of mess as it is now.
Comments (and patches) appreciated.
Table of contents (shortlog):
=============================
[PATCH 1/6] gitweb: Separate HTTP header output
[PATCH 2/6] gitweb: Add mod_perl version string to "generator" meta header
[PATCH 3/6] gitweb: Precompile CGI routines for mod_perl
[PATCH/RFC 4/6] gitweb: Prepare for mod_perl specific support
[RFC/PATCH 5/6] gitweb: Make possible to run under mod_perl without SetupEnv
[RFC/PATCH 6/6] gitweb: Make possible to run under mod_perl without ParseHeaders
Diffstat:
=========
gitweb/gitweb.perl | 227 +++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 205 insertions(+), 22 deletions(-)
Benchmarks:
===========
$ ab -n 10 "http://localhost/perl/gitweb/gitweb.cgi?p=git.git;a=summary"
$ ab -n 10 -c 2 "http://localhost/perl/gitweb/gitweb.cgi?p=git.git;a=summary"
(hot cache)
$ ab -n 10 "http://localhost/perl/gitweb/gitweb.cgi/git.git"
$ ab -n 10 -c 2 "http://localhost/perl/gitweb/gitweb.cgi/git.git"
(hot cache)
patch | mean +/- sd | mean -c 2
-----------------------------------------------------------------------------
[before first patch in series]: | 287 +/- 8.8 ms | 296.049 ms
(path_info version) | 293 +/- 10.6 ms | 314.526 ms
gitweb-Separate-HTTP-header-output: | 302 +/- 46.7 ms | 300.305 ms
gitweb-Add-mod_perl-to-generator: | 288 +/- 15.6 ms | 306.050 ms
gitweb-Precompile-CGI-routines-for-mod_perl: | 291 +/- 10.9 ms | 306.704 ms
gitweb-Prepare-for-mod_perl-specific-support: | 299 +/- 11.0 ms | 300.879 ms
gitweb-mod_perl-without-SetupEnv: | 288 +/- 12.4 ms | 296.809 ms
(path_info version) | 292 +/- 12.7 ms | 307.380 ms
gitweb-mod_perl-without-ParseHeaders: | ??? | ???
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Teach git-gc to only repack local (not borrowed) objects.
From: Shawn O. Pearce @ 2006-12-27 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This feature was suggested by Martin Waitz on the git mailing list
and is actually the correct thing to do. If the current repository
is borrowing objects from repository then this repository is not
usually considered to be maintaining the objects which are available
through that other repository's object database. We really should
only repack objects which are stored directly in this repository,
so supply -l to git-repack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gc.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gc.sh b/git-gc.sh
index e55ed19..6de55f7 100755
--- a/git-gc.sh
+++ b/git-gc.sh
@@ -10,6 +10,6 @@ SUBDIRECTORY_OK=Yes
git-pack-refs --prune &&
git-reflog expire --all &&
-git-repack -a -d &&
+git-repack -a -d -l &&
git-prune &&
git-rerere gc || exit
--
1.4.4.3.gd2e4
^ permalink raw reply related
* gcc -L/path/lib -R/path/lib
From: Junio C Hamano @ 2006-12-27 22:13 UTC (permalink / raw)
To: git
While trying git with cURL 7.16.0, I found that in my
environment (Debian x86-64, mostly testing, with gcc 4.1.2
prerelease), gcc does not seem to like -R/path/lib to be used to
specify the runtime library paths.
I am a bit surprised if nobody had this issue before, so I might
be reinventing the wheel and in a wrong/suboptimal way, but this
patch seems to work around the issue for me.
Comments?
diff --git a/Makefile b/Makefile
index 52d4a3a..7b24323 100644
--- a/Makefile
+++ b/Makefile
@@ -79,6 +79,10 @@ all:
#
# Define NO_ICONV if your libc does not properly support iconv.
#
+# Define NO_R_TO_GCC if your gcc does not like "-R/path/lib" that
+# tells runtime paths for dynamic libraries; "-Wl,-rpath=/path/lib"
+# is used instead.
+#
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
@@ -422,11 +426,19 @@ ifeq ($(uname_S),Darwin)
endif
endif
+ifdef NO_R_TO_GCC_LINKER
+ # Some gcc does not accept and pass -R to the linker to specify
+ # the runtime dynamic library path.
+ CC_LD_DYNPATH = -Wl,-rpath=
+else
+ CC_LD_DYNPATH = -R
+endif
+
ifndef NO_CURL
ifdef CURLDIR
- # This is still problematic -- gcc does not always want -R.
+ # Try "-Wl,-rpath=$(CURLDIR)/lib" in such a case.
BASIC_CFLAGS += -I$(CURLDIR)/include
- CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
+ CURL_LIBCURL = -L$(CURLDIR)/lib $(CC_LD_DYNPATH)$(CURLDIR)/lib -lcurl
else
CURL_LIBCURL = -lcurl
endif
@@ -445,9 +457,8 @@ endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
- # Again this may be problematic -- gcc does not always want -R.
BASIC_CFLAGS += -I$(OPENSSLDIR)/include
- OPENSSL_LINK = -L$(OPENSSLDIR)/lib -R$(OPENSSLDIR)/lib
+ OPENSSL_LINK = -L$(OPENSSLDIR)/lib $(CC_LD_DYNPATH)$(OPENSSLDIR)/lib
else
OPENSSL_LINK =
endif
@@ -463,9 +474,8 @@ else
endif
ifdef NEEDS_LIBICONV
ifdef ICONVDIR
- # Again this may be problematic -- gcc does not always want -R.
BASIC_CFLAGS += -I$(ICONVDIR)/include
- ICONV_LINK = -L$(ICONVDIR)/lib -R$(ICONVDIR)/lib
+ ICONV_LINK = -L$(ICONVDIR)/lib $(CC_LD_DYNPATH)$(ICONVDIR)/lib
else
ICONV_LINK =
endif
^ permalink raw reply related
* Re: git-add & "file vanishing" -> need git-add again [reformatted]
From: David Tweed @ 2006-12-27 21:58 UTC (permalink / raw)
To: git
This is a resend of previous mail reformatted.
(Unfortunately even university staff acounts
these days seem to only give you unconfigurable
web-browser interfaces; hopefully gmail won't butcher
the 72-character wrapped layout I'm seeing on my
screen right now too much.)
Many thanks for your forbearance and any insight.
Original message<<<<<<<<<<<<<<<<<<<<<<<<
Hi, I'm working on using git for chronological backups (think
selective P9 venti), which I've almost got working. (I know I'm using
git for something it wasn't designed for, and is arguably perverse.)
I've been trying to figure out why files which "ought" to be tracked
weren't in the database in certain commits and I think I've figured
out why. Can someone confirm the following: with the set of
operations
git-init-db ....
git-add path/to/fileX
git-commit -a -m blah <1>
..... changes to things including fileX and commits
[fileX vanishes from the tree being tracked, but nothing
mentioned to git] <2>
..... changes to things and commits
[file X reappears in the working tree being tracked]
<3>
git-commit -a -m blah <4>
The git trees from <1> to <2> all contain fileX, even if its contents
haven't changed. Between <2> and <4> the git tree doesn't contain
fileX (perfectly properly). From <4> onwards fileX still doesn't
appear in the git trees recorded from the working directory even
though fileX is there again. If I want fileX tracked I have to
explicitly git-add it again at <3>. (Ie, git-commit -a when it detects
a file have vanished from the working tree removes it from the files
git will look at in future for changes to commit.)
Is it also correct that this behaviour ("forget" about a tracked file
when it disappear from the working tree in a commit) would be
difficult to change without major surgery to git? Would there be any
problems with git-add'ing every file you want the tree to track before
every commit?
(I'm currently working on code to keep track of things that have ever
been tracked, and whether they're currently in the tree, in my scripts
outside git but obviously partially duplicating stuff git has in its
datastructures has the potential for subtle bugs when they diverge.)
Long story:
---------------
I'm trying to move a snapshotting-style system from my personal
hack-job to git. As well as manual snapshots there's a cron job that
runs every hour to snapshot stuff. Consequently there will be
"automatic commits" when you wouldn't have made one if you were doing
normal source control, eg, after you've wrongly deleted a file and
before you've noticed & restored it from the database an automatic
commit can come in (and even more kinky situations you don't want to
know about) and so sees the file "gone".
Sidenote: I'm moving the database from the old format to the new one
by repeatedly unpacking the old database for snapshot X, git-add'ing
any file names which have _never_ been in any snapshot before,
git-commit -a, git-tag, then remove all the files unpacked by the old
database and move onto snapshot X+1. This takes less than a second per
snapshot. I understand this shouldn't be a problem but just to let
people know the timestamps on the files aren't what would be expected.
Follow up clarification msg <<<<<<<<<<<<<<<<<<<<<<<<
|Not sure how large your snapshots are -- a
|second sounds like a long time for git operations. While it is a bit
|more complex, you _can_ operate directly on the index, and the
|"snapshot" never needs to hit the disk as such during your migration.
By trying to be brief I was a rather cryptic. What I was trying to say
was:
Running the git commands earlier in the message in a script, I see
that file are not present from the git tree generated by a commit at a
time when I know the file I'd previously git-added reappeared in the
working directory. I'm hypothesising that this is because when the
file disappears the machinery in git loses the `track this file'
information. However, I haven't (and would prefer not to) dig into the
git code to check that's the correct explanation. If this is why the
files aren't being tracked I can try to script around the issue by
git-adding all the files I want tracked by the snapshot before the
git-commit -a. To help anyone thinking about if the explanation is
right, the working directory is repeatedly being wiped and refilled
from my old backup system with a second, so often all files have both
creation and modification times set to the current second. This is a
really weird thing to do and might in some way be responsible for the
untracked file (cf racy-git)."
Most of the maybe half-second overhead is coming from my script
unpacking the files with gzip from my old database; git seems more
than fast enough.
|Have a look at how the cvsimport script works for an example.
As its my personal db which I'll only convert once if I can just make
replaying work I don't need anything more complicated; I've only got
2000-odd snapshots.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
^ permalink raw reply
* Re: http git and curl 7.16.0
From: Junio C Hamano @ 2006-12-27 21:46 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Nick Hengeveld, George Sherwood, skimo, git
In-Reply-To: <7vlkkt5d49.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>>> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.
>>> It worked fine with curl 7.15.0.
>>
>> It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while
>> it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.
>>
>> Furthermore, with new curl pulling from HTTP repos when there are updates
>> gives double free errors and a crash.
>
> Hmmm. Could somebody please run http-fetch under gdb and see
> where it breaks? The exact command line you need to use would
> be obtainable by running "sh -x git-clone" once.
>
> [jc: Nick CC'ed, although I haven't seen him on the list for
> some time...]
When we do not have NO_CURL_EASY_DUPHANDLE defined, http.c
prepares a single "CURL *curl_default" with get_curl_handle(),
and new request slots clone it using curl_easy_duphandle().
However, the returned "clone" somehow forgets to set the "magic"
number that says it is a GOOD_EASY_HANDLE(). This missing magic
number is checked by cURL library in curl_multi_add_handle(),
which we call from start_active_slot(). Hence the request
fails.
Now, I do not know cURL, and cannot tell if it is just a bug in
easy-duphandle of curl 7.16.0, or if we are not supposed to be
using the "easy" interface when dealing with multi fetch. In
either case, the attached patch seems to fix it for me.
I am NOT CC'ing curl-library@cool.haxx.se mailing list since I
do not want to subscribe only to be able to post, but some kind
souls who are subscribers could forward the issue to them to
determine if we need to fix our code (and if so how), or if we
need to wait for them to fix curl_easy_duphandle().
-- >8 --
diff --git a/http.h b/http.h
index 6e12e41..70b18dd 100644
--- a/http.h
+++ b/http.h
@@ -18,7 +18,7 @@
#define curl_global_init(a) do { /* nothing */ } while(0)
#endif
-#if LIBCURL_VERSION_NUM < 0x070c04
+#if 1 || (LIBCURL_VERSION_NUM < 0x070c04)
#define NO_CURL_EASY_DUPHANDLE
#endif
^ permalink raw reply related
* Re: branch.pu.forcefetch
From: Jakub Narebski @ 2006-12-27 21:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyb159dn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
>> For example, I clone the git repository anew, and I try to update it by
>> git-fetch a few days later. I get an error:
>>
>> * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
>> of git://www.kernel.org/pub/scm/git/git
>
> Perhaps you would want something like this?
>
> if you are using separate remote layout:
>
> [remote "origin"]
> fetch = +refs/heads/pu:refs/remotes/origin/pu
> fetch = refs/heads/*:refs/remotes/origin/*
By the way, does the ordering matter here, i.e. does it matter if 'pu' fetch
line is before or after wildcards line?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: branch.pu.forcefetch
From: Junio C Hamano @ 2006-12-27 21:14 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1167251519.2247.10.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> For example, I clone the git repository anew, and I try to update it by
> git-fetch a few days later. I get an error:
>
> * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
> of git://www.kernel.org/pub/scm/git/git
Perhaps you would want something like this?
if you are using separate remote layout:
[remote "origin"]
fetch = +refs/heads/pu:refs/remotes/origin/pu
fetch = refs/heads/*:refs/remotes/origin/*
Or traditional layout:
[remote "origin"]
fetch = refs/heads/master:refs/heads/origin
fetch = refs/heads/next:refs/heads/next
fetch = refs/heads/maint:refs/heads/maint
fetch = +refs/heads/pu:refs/remotes/pu
^ permalink raw reply
* Re: branch.pu.forcefetch
From: Jakub Narebski @ 2006-12-27 21:14 UTC (permalink / raw)
To: git
In-Reply-To: <1167251519.2247.10.camel@dv>
Pavel Roskin wrote:
> I'm testing the current git from the master branch, and I like the idea
> of moving the remotes to the config file, but I think there is a
> significant omission in the new syntax. There is no way to specify that
> some branches are fast forward.
>
> For example, I clone the git repository anew, and I try to update it by
> git-fetch a few days later. I get an error:
>
> * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
> of git://www.kernel.org/pub/scm/git/git
>
> It would be great to have a "non-fastforward" option in the config file
> for every branch. I'm thinking about something like:
>
> [branch "pu"]
> forcefetch = 1
Currently the old '+' before refspec still works. So you should have
[remote "origin"]
# ...
fetch = +refs/heads/pu:refs/remotes/origin/pu
> It would be even better to initialize such option while cloning.
There was some talk about this, but I don't remember if there were any code.
Actually the talk was about marking branch as non-fast-forwardable (which
is meant to have rewritten history) on _server_ side, and allowing to
fetch all/parts of config while cloning to get this info.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* git-cvsimport doesn't support the default branch mechanism?
From: Hannu Koivisto @ 2006-12-27 21:03 UTC (permalink / raw)
To: git
Greetings,
I tried to git-cvsimport an existing project but there seemed to be
something wrong with the result. On closer inspection I noticed
that contents of files that had never been modified in trunk
corresponded to revision 1.1 instead of the tip of the vendor
branch in the generated master and origin branches.
In other words (using zsh):
> mkdir test
> cd test
> mkdir repo
> export CVSROOT=`pwd`/repo
> cvs init
> mkdir foo
> cd foo
> echo lahna > kala.txt
> cvs import -m "Initial vendor import." foo vendor vendor-v1
> cd ..
> rm -r foo
> cvs co foo
> cd foo
> cvs up -rvendor
> echo hauki >! kala.txt
> cvs commit -m "Fake 2nd. vendor import."
> cvs up -A
> cat kala.txt
hauki
> cd ..
> git-cvsimport -d $CVSROOT -C foo.git foo
> cd foo.git
> git-checkout -f master
> cat kala.txt
lahna
I would have expected to get "hauki" from that last "cat kala.txt"
as well. Is this a known problem or a feature? In either case, how
should I work around it?
--
Hannu
^ permalink raw reply
* branch.pu.forcefetch
From: Pavel Roskin @ 2006-12-27 20:31 UTC (permalink / raw)
To: git
Hello!
I'm testing the current git from the master branch, and I like the idea
of moving the remotes to the config file, but I think there is a
significant omission in the new syntax. There is no way to specify that
some branches are fast forward.
For example, I clone the git repository anew, and I try to update it by
git-fetch a few days later. I get an error:
* refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
of git://www.kernel.org/pub/scm/git/git
It would be great to have a "non-fastforward" option in the config file
for every branch. I'm thinking about something like:
[branch "pu"]
forcefetch = 1
It would be even better to initialize such option while cloning.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: http git and curl 7.16.0
From: Junio C Hamano @ 2006-12-27 19:53 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Nick Hengeveld, George Sherwood, skimo, git
In-Reply-To: <200612271457.kBREvkj2011916@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Sven Verdoolaege <skimo@kotnet.org> wrote:
>> On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote:
>> > I seem to be having a problem doing an http checkout with git built
>> > with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a
>> > clone, I get:
> ...
>> > git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
>> > error: Unable to start request error: Could not interpret heads/master
>> > as something to pull
>> >
>> > If I rebuild git against curl 7.15.5 then I get:
>> [..]
>> > and the checkout finishes.
>> >
>> > Has any one else seen this?
>
>> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.
>> It worked fine with curl 7.15.0.
>
> It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while
> it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.
>
> Furthermore, with new curl pulling from HTTP repos when there are updates
> gives double free errors and a crash.
Hmmm. Could somebody please run http-fetch under gdb and see
where it breaks? The exact command line you need to use would
be obtainable by running "sh -x git-clone" once.
[jc: Nick CC'ed, although I haven't seen him on the list for
some time...]
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-27 19:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612271312.15877.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> ... I don't
> know, perhaps "git reflog expire --all" does that: but there is no
> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
> but 1.4.4.3)...
If that is the case, may I ask you to at least please make it a
habit to read what are relevant to the topic under discussion
before jumping in? The list traffic is already high enough that
I am spending a lot of time just to skim all the messages posted
here -- I think that time is better spent on development and
improvements.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-27 19:42 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Jakub Narebski, git
In-Reply-To: <200612271300.kBRD082j007703@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Jakub Narebski <jnareb@gmail.com> wrote:
>
> [...]
>
>> Perhaps that is the idea, but that idea is not described in above
>> new feature announcement. "... to reencode the message to UTF-8
>> when displaying, if needed." would cover it, but perhaps better
>> would be to cover this in more detail: "reencode message to UTF-8
>> if i18n.commitencoding is not set to something other than UTF-8",
>> or "reencode ... to i18n.commitencoding ... if needed".
>
> And what happens to the people who can't/won't display UTF-8? This is a
> both a project wide configuration (how does stuff get saved) + a user/local
> configuration (how to display stuff).
Presumably you would do something like:
git log | tcs -f utf -t latin1 | less
The point being that the input to tcs will be uniformly UTF-8
even the committers used Latin-1 and UTF-8, either carelessly or
deliberately [*1*].
Maybe i18n.displayencoding set to latin1 is what you are after?
I think it might make sense...
In any case, as Jakub and others pointed out, the description
was not nice nor clear. How about this as an update?
* I18n
- We have always encouraged the commit message to be encoded in
UTF-8, but the users are allowed to use legacy encoding as
appropriate for their projects. This will continue to be the
case. However, a non UTF-8 commit encoding _must_ be
explicitly set with i18n.commitencoding in the repository
where a commit is made; otherwise git-commit-tree will
complain if the log message does not look like a valid UTF-8
string.
[Side note: in v1.5.0 preview, it only warns about this
situation; I have a feeling that it might be better to promote
this to an error and refuse to commit until the user sets
i18n.commitencoding to the name of the legacy encoding used for
the project -- this will be a one-time inconvenience but will
be much better in the long run.]
- The value of i18n.commitencoding in the originating
repository is recorded in the commit object on the "encoding"
header, if it is not UTF-8. git-log and friends notice this,
and reencodes the message to the encoding specified with
i18n.commitencoding when displaying, if they are different.
[Footnote]
*1* For encoding as simple as Latin I do not think it is an
issue, but we do not want to encode everything to UTF-8 at
commit time, because non-reversible conversion can lose
information. I do not want to rule out a situation where a
particular commit log entry needs to be in an encoding different
from the project norm, which hopefully is UTF-8, because it
needs to describe something in a character that cannot be
reversibly converted to UTF-8 (maybe the project is about iconv
enhancement, the commit fixes something related to irreversible
conversion and the log message wants to give an example).
^ permalink raw reply
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Junio C Hamano @ 2006-12-27 18:46 UTC (permalink / raw)
To: Martin Waitz; +Cc: Shawn O. Pearce, git
In-Reply-To: <20061227131113.GB6115@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> On Wed, Dec 27, 2006 at 02:17:59AM -0500, Shawn O. Pearce wrote:
>> Junio asked for a 'git gc' utility which users can execute on a
>> regular basis to perform basic repository actions such as:
>>
>> * pack-refs --prune
>> * reflog expire
>> * repack -a -d
>
> what about doing "git-repack -a -d -l" by default?
I think that is sensible.
^ permalink raw reply
* Re: http git and curl 7.16.0
From: Horst H. von Brand @ 2006-12-27 14:57 UTC (permalink / raw)
To: skimo; +Cc: George Sherwood, Git List
In-Reply-To: <20061217113235.GJ25274MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote:
> > I seem to be having a problem doing an http checkout with git built
> > with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a
> > clone, I get:
> > git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
> > error: Unable to start request error: Could not interpret heads/master
> > as something to pull
> >
> > If I rebuild git against curl 7.15.5 then I get:
> [..]
> > and the checkout finishes.
> >
> > Has any one else seen this?
> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.
> It worked fine with curl 7.15.0.
It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while
it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.
Furthermore, with new curl pulling from HTTP repos when there are updates
gives double free errors and a crash.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* [PATCH] gitweb: Re-enable rev-list --parents for parse_commit.
From: Robert Fitzsimons @ 2006-12-27 14:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <empkcf$qp$1@sea.gmane.org>
Re-enable rev-list --parents for parse_commit which was removed in
(208b2dff95bb48682c351099023a1cbb0e1edf26). rev-list --parents is not
just used to return the parent headers in the commit object, it
includes any grafts which are vaild for the commit.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
> Actually --header output gives us original parents. Rewritten parents
> (available with --parents) include also grafts and shallow clone grafts.
> For parse_commit we want --parents, for parse_commits we don't want it
> because --parents affects --full-history.
Heres a patch the re-enables --parents for parse_commit.
Robert
gitweb/gitweb.perl | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 65fcdb0..da12be7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1271,7 +1271,7 @@ sub parse_tag {
}
sub parse_commit_text {
- my ($commit_text) = @_;
+ my ($commit_text, $withparents) = @_;
my @commit_lines = split '\n', $commit_text;
my %co;
@@ -1281,13 +1281,12 @@ sub parse_commit_text {
if (!($header =~ m/^[0-9a-fA-F]{40}/)) {
return;
}
- $co{'id'} = $header;
- my @parents;
+ ($co{'id'}, my @parents) = split ' ', $header;
while (my $line = shift @commit_lines) {
last if $line eq "\n";
if ($line =~ m/^tree ([0-9a-fA-F]{40})$/) {
$co{'tree'} = $1;
- } elsif ($line =~ m/^parent ([0-9a-fA-F]{40})$/) {
+ } elsif ((!defined $withparents) && ($line =~ m/^parent ([0-9a-fA-F]{40})$/)) {
push @parents, $1;
} elsif ($line =~ m/^author (.*) ([0-9]+) (.*)$/) {
$co{'author'} = $1;
@@ -1373,12 +1372,13 @@ sub parse_commit {
local $/ = "\0";
open my $fd, "-|", git_cmd(), "rev-list",
+ "--parents",
"--header",
"--max-count=1",
$commit_id,
"--",
or die_error(undef, "Open git-rev-list failed");
- %co = parse_commit_text(<$fd>);
+ %co = parse_commit_text(<$fd>, 1);
close $fd;
return %co;
--
1.4.4.3.g6934
^ permalink raw reply related
* [PATCH] git-send-email: default value for "From:" field.
From: Quy Tonthat @ 2006-12-27 14:16 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200612271343.kBRDhKfA009927@laptop13.inf.utfsm.cl>
If user hits enter at the prompt for
"Who should the emails appear to be from?",
the value for "From:" field was emptied instead of GIT_COMMITER_IDENT.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
It seems the original code assumes readline to accept
an extra argument for default value. I don't remember I ever encountered
that feature from readline. Is there anything like that out there ?
git-send-email.perl | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4c87c20..ba39d39 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -178,11 +178,10 @@ my $prompting = 0;
if (!defined $from) {
$from = $author || $committer;
do {
- $_ = $term->readline("Who should the emails appear to be from? ",
- $from);
+ $_ = $term->readline("Who should the emails appear to be from? [$from] ");
} while (!defined $_);
- $from = $_;
+ $from = $_ if ($_);
print "Emails will be sent from: ", $from, "\n";
$prompting++;
}
--
1.4.4.3.q5
^ permalink raw reply related
* git-1.4.4.3, also 1.5.0rc0: send-email gets empty From:
From: Horst H. von Brand @ 2006-12-27 13:43 UTC (permalink / raw)
To: git
I updated a local project, git-format-patch:ed, and then:
$ git send-email --to=olpc@listas.inf.utfsm.cl --no-signed-off-by-cc /tmp/0001-Add-myself-to-AUTHORS.txt
Who should the emails appear to be from?
Emails will be sent from:
Message-ID to be used as In-Reply-To for the first email?
/tmp/0001-Add-myself-to-AUTHORS.txt
Use of uninitialized value in concatenation (.) or string at /usr/bin/git-send-email line 392.
(mbox) Adding cc: Horst H. von Brand <vonbrand@inf.utfsm.cl> from line 'From: Horst H. von Brand <vonbrand@inf.utfsm.cl>'
OK. Log says:
Date: Wed, 27 Dec 2006 10:27:39 -0300
Sendmail: /usr/sbin/sendmail
From:
Subject: [PATCH] Add myself to AUTHORS
Cc: Horst H. von Brand <vonbrand@inf.utfsm.cl>
To: olpc@listas.inf.utfsm.cl
Result: OK
I didn't add a From:, per manpage it is assumed to be GIT_COMMITER_IDENT
(from 'git-var -l' this is 'Horst H. von Brand <vonbrand@inf.utfsm.cl> 1167226309 -0300').
Note particularly the "Emails will be sent from:" line!
The resulting message is formed right (it has a From: header), so this is
just a UI glitch.
The same output from 1.5.0rc0 here.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Martin Waitz @ 2006-12-27 13:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061227071759.GA23057@spearce.org>
hoi :)
On Wed, Dec 27, 2006 at 02:17:59AM -0500, Shawn O. Pearce wrote:
> Junio asked for a 'git gc' utility which users can execute on a
> regular basis to perform basic repository actions such as:
>
> * pack-refs --prune
> * reflog expire
> * repack -a -d
what about doing "git-repack -a -d -l" by default?
--
Martin Waitz
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Horst H. von Brand @ 2006-12-27 13:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200612271312.15877.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> Perhaps that is the idea, but that idea is not described in above
> new feature announcement. "... to reencode the message to UTF-8
> when displaying, if needed." would cover it, but perhaps better
> would be to cover this in more detail: "reencode message to UTF-8
> if i18n.commitencoding is not set to something other than UTF-8",
> or "reencode ... to i18n.commitencoding ... if needed".
And what happens to the people who can't/won't display UTF-8? This is a
both a project wide configuration (how does stuff get saved) + a user/local
configuration (how to display stuff).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: Segfault in xdl_merge is back
From: Alexandre Julliard @ 2006-12-27 12:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612271214120.19693@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 5127 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> As you said in another mail, Junio suggested using git-merge-file on the
> blobs themselves. This is a little tricky, since git-merge-file does not
> read blobs; only files. I'd do this:
>
> - in merge-recursive.c just before line 658 I'd add an
> fprintf(stderr, "xdl_merge: %s %s %s\n", sha1_to_hex(a->sha1),
> sha1_to_hex(o->sha1), sha1_to_hex(b->sha1));
> - run the merge until it segfaults
> - get the blobs by using the last three SHA1's in the output by
> $ git-show <sha1> > a # or "o" or "b"
> - $ git merge-file -p a o b >/dev/null
>
> This command line ensures that "a" is not edited, and you can repeat the
> merge as often as needed.
I'm seeing the problem here on Linux, I have attached a tarball with
a set of files from Wine that trigger the bug.
The gdb backtrace looks like this:
Core was generated by `git-merge-file -p a o b'.
Program terminated with signal 11, Segmentation fault.
#0 0x080b60be in xdl_refine_conflicts (xe1=0xbfcaf22c, xe2=0xbfcaf1a4, m=0x8106668, xpp=0xbfcaf348) at xdiff/xmerge.c:197
197 t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
(gdb) bt
#0 0x080b60be in xdl_refine_conflicts (xe1=0xbfcaf22c, xe2=0xbfcaf1a4, m=0x8106668, xpp=0xbfcaf348) at xdiff/xmerge.c:197
#1 0x080b6843 in xdl_do_merge (xe1=0xbfcaf22c, xscr1=0x0, name1=0xbfcafbcf "a", xe2=0xbfcaf1a4, xscr2=0x0, name2=0xbfcafbd3 "b", level=2, xpp=0xbfcaf348, result=0xbfcaf34c) at xdiff/xmerge.c:351
#2 0x080b6b8c in xdl_merge (orig=0xbfcaf35c, mf1=0xbfcaf354, name1=0xbfcafbcf "a", mf2=0xbfcaf364, name2=0xbfcafbd3 "b", xpp=0xbfcaf348, level=2, result=0xbfcaf34c) at xdiff/xmerge.c:408
#3 0x08067887 in cmd_merge_file (argc=4, argv=0xbfcaf4b8, envp=0x0) at builtin-merge-file.c:43
#4 0x0804b0e5 in handle_internal_command (argc=5, argv=0xbfcaf4b4, envp=0xbfcaf4cc) at git.c:294
#5 0x0804b1e7 in main (argc=5, argv=0xbfcaf4b4, envp=0xbfcaf4cc) at git.c:331
(gdb) p *xe1
$1 = {xdf1 = {rcha = {head = 0x8105ca8, tail = 0x8107558, isize = 16, nsize = 1056, ancur = 0x8107558, sncur = 0x0, scurr = 0}, nrec = 259, hbits = 9, rhash = 0x81054a0, dstart = 36, dend = 257,
recs = 0x8105080, rchg = 0x80ff009 "", rindex = 0x8107988, nreff = 18, ha = 0x8107da0}, xdf2 = {rcha = {head = 0x8108370, tail = 0x81085b0, isize = 16, nsize = 176, ancur = 0x81085b0, sncur = 0x0,
scurr = 0}, nrec = 41, hbits = 6, rhash = 0x8108268, dstart = 36, dend = 39, recs = 0x81081b8, rchg = 0x80ff119 "", rindex = 0x8108670, nreff = 3, ha = 0x8108720}}
(gdb) p *xe2
$2 = {xdf1 = {rcha = {head = 0x81060d8, tail = 0x810aad0, isize = 16, nsize = 1056, ancur = 0x810aad0, sncur = 0x0, scurr = 0}, nrec = 259, hbits = 9, rhash = 0x8104878, dstart = 44, dend = 43,
recs = 0x8106b18, rchg = 0x8106509 "", rindex = 0x810b998, nreff = 0, ha = 0x810bdb0}, xdf2 = {rcha = {head = 0x810ce20, tail = 0x810db40, isize = 16, nsize = 1104, ancur = 0x810db40, sncur = 0x0,
scurr = 0}, nrec = 270, hbits = 9, rhash = 0x810c618, dstart = 44, dend = 54, recs = 0x810c1c8, rchg = 0x8106f39 "", rindex = 0x810dfa0, nreff = 8, ha = 0x810e3e0}}
(gdb) p *m
$3 = {next = 0x0, mode = 0, i1 = 41, i2 = 41, chg1 = 0, chg2 = 229}
And here's the Valgrind output:
==32758== Memcheck, a memory error detector.
==32758== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==32758== Using LibVEX rev 1658, a library for dynamic binary translation.
==32758== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==32758== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==32758== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==32758== For more details, rerun with: -v
==32758==
==32758== Use of uninitialised value of size 4
==32758== at 0x80B60BE: xdl_refine_conflicts (xmerge.c:197)
==32758== by 0x80B6842: xdl_do_merge (xmerge.c:351)
==32758== by 0x80B6B8B: xdl_merge (xmerge.c:408)
==32758== by 0x8067886: cmd_merge_file (builtin-merge-file.c:43)
==32758== by 0x804B0E4: handle_internal_command (git.c:294)
==32758== by 0x804B1E6: main (git.c:331)
==32758==
==32758== Invalid read of size 4
==32758== at 0x80B60BE: xdl_refine_conflicts (xmerge.c:197)
==32758== by 0x80B6842: xdl_do_merge (xmerge.c:351)
==32758== by 0x80B6B8B: xdl_merge (xmerge.c:408)
==32758== by 0x8067886: cmd_merge_file (builtin-merge-file.c:43)
==32758== by 0x804B0E4: handle_internal_command (git.c:294)
==32758== by 0x804B1E6: main (git.c:331)
==32758== Address 0x4 is not stack'd, malloc'd or (recently) free'd
==32758==
==32758== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==32758== Access not within mapped region at address 0x4
==32758== at 0x80B60BE: xdl_refine_conflicts (xmerge.c:197)
==32758== by 0x80B6842: xdl_do_merge (xmerge.c:351)
==32758== by 0x80B6B8B: xdl_merge (xmerge.c:408)
==32758== by 0x8067886: cmd_merge_file (builtin-merge-file.c:43)
==32758== by 0x804B0E4: handle_internal_command (git.c:294)
==32758== by 0x804B1E6: main (git.c:331)
Hope this helps,
--
Alexandre Julliard
julliard@winehq.org
[-- Attachment #2: merge-file-segfault.tar.gz --]
[-- Type: application/octet-stream, Size: 2785 bytes --]
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Jakub Narebski @ 2006-12-27 12:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612271251060.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> BTW I think that latin-1 is not a valid encoding name (at least in my
> setup it isn't), so we should rather talk about iso-8859-1.
"iconv --list" include l1 and latin1 as aliases to the proper name
of encoding, i.e. iso-8859-1; but not latin-2.
--
Jakub Narebski
Poland
^ 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