* Re: CFT: merge-recursive in C (updated)
From: Alex Riesen @ 2006-06-28 14:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606281342290.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/28/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > What stands out next is getRenames (to be renamed into get_renames), a
> > little profiling shows that the renames lists are the culprit this time
> > too.
>
> In my attempts, the path_list did not contain paths, but structs
> containing a path and a void pointer. I think I will resurrect this idea
> for the renames.
>
What was the pointer for?
^ permalink raw reply
* Re: CFT: merge-recursive in C (updated)
From: Johannes Schindelin @ 2006-06-28 12:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0606280435t70ac9957jae2c4d1c10b7681d@mail.gmail.com>
Hi,
On Wed, 28 Jun 2006, Alex Riesen wrote:
> What stands out next is getRenames (to be renamed into get_renames), a
> little profiling shows that the renames lists are the culprit this time
> too.
In my attempts, the path_list did not contain paths, but structs
containing a path and a void pointer. I think I will resurrect this idea
for the renames.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git.c: Re-introduce sane error messages on missing commands.
From: Marco Roeland @ 2006-06-28 12:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0606281240480.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Wednesday June 28th 2006 Johannes Schindelin wrote:
> [PATCH] save errno in handle_alias()
>
> git.c:main() relies on the value of errno being set by the last attempt to
> execute the command. However, if something goes awry in handle_alias(),
> that assumption is wrong. So restore errno before returning from
> handle_alias().
If we rely on the value of errno we should always immediately store it's
value anyway. On some neolithic systems like the "MSVCRT.DLL" C runtime
library on Windows (used by e.g. the Mingw compiler, don't know about
Cygwin) a lot of runtime functions actually even reset the value of
errno to 0 on success!
--
Marco Roeland
^ permalink raw reply
* Re: [PATCH] git.c: Re-introduce sane error messages on missing commands.
From: Andreas Ericsson @ 2006-06-28 11:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606281240480.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 28 Jun 2006, Junio C Hamano wrote:
>
>
>>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>
>>>Try this:
>>>
>>>$ mkdir 5
>>>$ cd 5
>>>$ git-init-db
>>>$ rm .git/config # yes, really.
>>>$ git abc
>>
>>Thanks for trying to help, but not really.
>
>
> Okay. Does not happen with 'next' here, too. I have some changes in my
> private repo (which eventually should culminate in the big mmap()ed sooper
> config parsing / writing thingie), which make it break. The following
> patch fixes this (and potentially Andreas' problem, too).
>
It should, although the command it tried to execute will still be empty
if it fails for some other reason (file not executable / permission
denied), since it only does the right thing on ENOENT.
This is also, imo, a bit worse than preserving the errno from the
execve() call in the caller, since errno is sometimes a macro (yes, only
in threaded apps atm, but still...), and it will be easy to forget to
look in handle_alias() if other things change in main() that makes this
bug resurface.
Oh, and the part of my patch removing the git_command variable from
git.c:main() still has to be applied for arbitrary error-messages to
look sane.
$ grep -B1 git_command git.c
char *slash = strrchr(cmd, '/');
char git_command[PATH_MAX + 1];
--
fprintf(stderr, "Failed to run command '%s': %s\n",
git_command, strerror(errno));
Btw, Junio, did you try this with 'master' as of yesterday morning (git
version 1.4.1.rc1.g1ef9)? It's reproducible on every machine I've tried
so far (well, only five, but still), so it seems odd that you don't see it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: CFT: merge-recursive in C (updated)
From: Alex Riesen @ 2006-06-28 11:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0606281202360.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/28/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > > - use a pipe to "git-update-index --index-info" instead of using command
> > > > > line
> >
> > ...and to take it a step further, a patch (0002) to avoid too many calls to
> > git-write-tree and to git-update-index.
>
> ... and introduces a lot more lines doing debug output.
well, that's how I found out about what to fix. Was really impressed
when saw the difference :)
What stands out next is getRenames (to be renamed into get_renames),
a little profiling shows that the renames lists are the culprit this time too.
I actually expected these problems, but decided to postpone the
optimization for later: linked lists are comfortable to work with.
I didn't had much time for this project, and the first commit is
dated 7th June - it was a very slow progress.
> However, the change is good, but I would not call it "FILE *fp". IMHO
> "FILE *update_index_pipe" would explain better what you do there.
just update_index would be enough. It can't possibly mean anything else,
being FILE* in that context.
By the way, is it safe to use "git-update-index --index-info"?
AFAICS it was designed for this kind of use, but the most
visible user of it (git-update-recursive.py) didn't use --index-info
this way! Was there any specific reasons?
^ permalink raw reply
* Re: [PATCH] cvsimport - cleanup of the multi-indexes handling
From: Junio C Hamano @ 2006-06-28 11:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, junkio, Johannes.Schindelin
In-Reply-To: <11514896033560-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> Indexes are only needed when we are about preparing to commit. Prime them
> inside commit() when we have all the info we need, and remove all the
> redundant index setups.
Obviously makes sense although I admit I do not have to interact
with CVS these days anymore (lucky me ;-).
^ permalink raw reply
* Re: [PATCH] git.c: Re-introduce sane error messages on missing commands.
From: Johannes Schindelin @ 2006-06-28 10:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vr71938t4.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 28 Jun 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Try this:
> >
> > $ mkdir 5
> > $ cd 5
> > $ git-init-db
> > $ rm .git/config # yes, really.
> > $ git abc
>
> Thanks for trying to help, but not really.
Okay. Does not happen with 'next' here, too. I have some changes in my
private repo (which eventually should culminate in the big mmap()ed sooper
config parsing / writing thingie), which make it break. The following
patch fixes this (and potentially Andreas' problem, too).
-- cut here --
[PATCH] save errno in handle_alias()
git.c:main() relies on the value of errno being set by the last attempt to
execute the command. However, if something goes awry in handle_alias(),
that assumption is wrong. So restore errno before returning from
handle_alias().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
diff --git a/git.c b/git.c
index 94e9a4a..7c7106e 100644
--- a/git.c
+++ b/git.c
@@ -99,7 +99,7 @@ static int split_cmdline(char *cmdline,
static int handle_alias(int *argcp, const char ***argv)
{
- int nongit = 0, ret = 0;
+ int nongit = 0, ret = 0, saved_errno = errno;
const char *subdir;
subdir = setup_git_directory_gently(&nongit);
@@ -137,6 +137,8 @@ static int handle_alias(int *argcp, cons
if (subdir)
chdir(subdir);
+ errno = saved_errno;
+
return ret;
}
^ permalink raw reply related
* [PATCH (fixed) 1/2] rebase: check for errors from git-commit
From: Eric Wong @ 2006-06-28 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
commit does not always succeed, so we'll have to check for
it in the absence of set -e. This fixes a regression
introduced in 9e4bc7dd1bb9d92491c475cec55147fa0b3f954d
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-rebase.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 9ad1c44..28860fc 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -59,8 +59,13 @@ continue_merge () {
if test -n "`git-diff-index HEAD`"
then
+ if ! git-commit -C "`cat $dotest/current`"
+ then
+ echo "Commit failed, please do not call \"git commit\""
+ echo "directly, but instead do one of the following: "
+ die "$RESOLVEMSG"
+ fi
printf "Committed: %0${prec}d" $msgnum
- git-commit -C "`cat $dotest/current`"
else
printf "Already applied: %0${prec}d" $msgnum
fi
--
1.4.1.rc1.gc7c5
^ permalink raw reply related
* Re: Quick merge status updates.
From: Junio C Hamano @ 2006-06-28 10:14 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1151489103.28036.6.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> I think my Perl 5.8.8 is "too new". "man perlfunc" says about "use":
> ...
> I think the BEGIN block has priority over other statements. My solution
> was to put the @INC change in the BEGIN block as well.
Actually I do use 5.8.8 and everything you quoted makes perfect
sense, -- in fact now I do not know *why* it did _not_ break for
me without the BEGIN {} block, especially I do not have any
PERL* environment variable to point at anywhere under $HOME.
Thanks for the fix.
^ permalink raw reply
* [PATCH] cvsimport - cleanup of the multi-indexes handling
From: Martin Langhoff @ 2006-06-28 10:13 UTC (permalink / raw)
To: git, junkio, Johannes.Schindelin; +Cc: Martin Langhoff
Indexes are only needed when we are about preparing to commit. Prime them
inside commit() when we have all the info we need, and remove all the
redundant index setups.
While we are at it, make sure that index handling is correct when opening
new branches, and on initial import.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
This has passed some light testing. Applies on top of master, and seems to
do the right thing with tidier code . It even makes sense ;-)
---
git-cvsimport.perl | 62 ++++++++++++++++++++--------------------------------
1 files changed, 24 insertions(+), 38 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 50f5d96..9fa598a 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -467,11 +467,6 @@ my $orig_git_index;
$orig_git_index = $ENV{GIT_INDEX_FILE} if exists $ENV{GIT_INDEX_FILE};
my %index; # holds filenames of one index per branch
-$index{$opt_o} = tmpnam();
-
-$ENV{GIT_INDEX_FILE} = $index{$opt_o};
-system("git-read-tree", $opt_o);
-die "read-tree failed: $?\n" if $?;
unless(-d $git_dir) {
system("git-init-db");
@@ -499,14 +494,6 @@ unless(-d $git_dir) {
$orig_branch = $last_branch;
$tip_at_start = `git-rev-parse --verify HEAD`;
- # populate index
- unless ($index{$last_branch}) {
- $index{$last_branch} = tmpnam();
- }
- $ENV{GIT_INDEX_FILE} = $index{$last_branch};
- system('git-read-tree', $last_branch);
- die "read-tree failed: $?\n" if $?;
-
# Get the last import timestamps
opendir(D,"$git_dir/refs/heads");
while(defined(my $head = readdir(D))) {
@@ -623,6 +610,27 @@ # commits that cvsps cannot place anywhe
$ignorebranch{'#CVSPS_NO_BRANCH'} = 1;
sub commit {
+ if ($branch eq $opt_o && !$index{branch} && !get_headref($branch, $git_dir)) {
+ # looks like an initial commit
+ # use the index primed by git-init-db
+ $ENV{GIT_INDEX_FILE} = '.git/index';
+ $index{$branch} = '.git/index';
+ } else {
+ # use an index per branch to speed up
+ # imports of projects with many branches
+ unless ($index{$branch}) {
+ $index{$branch} = tmpnam();
+ $ENV{GIT_INDEX_FILE} = $index{$branch};
+ if ($ancestor) {
+ system("git-read-tree", $ancestor);
+ } else {
+ system("git-read-tree", $branch);
+ }
+ die "read-tree failed: $?\n" if $?;
+ }
+ }
+ $ENV{GIT_INDEX_FILE} = $index{$branch};
+
update_index(@old, @new);
@old = @new = ();
my $tree = write_tree();
@@ -811,30 +819,6 @@ while(<CVS>) {
close(H)
or die "Could not write branch $branch: $!";
}
- if(($ancestor || $branch) ne $last_branch) {
- print "Switching from $last_branch to $branch\n" if $opt_v;
- unless ($index{$branch}) {
- $index{$branch} = tmpnam();
- $ENV{GIT_INDEX_FILE} = $index{$branch};
- system("git-read-tree", $branch);
- die "read-tree failed: $?\n" if $?;
- }
- # just in case
- $ENV{GIT_INDEX_FILE} = $index{$branch};
- if ($ancestor) {
- print "have ancestor $ancestor" if $opt_v;
- system("git-read-tree", $ancestor);
- die "read-tree failed: $?\n" if $?;
- }
- } else {
- # just in case
- unless ($index{$branch}) {
- $index{$branch} = tmpnam();
- $ENV{GIT_INDEX_FILE} = $index{$branch};
- system("git-read-tree", $branch);
- die "read-tree failed: $?\n" if $?;
- }
- }
$last_branch = $branch if $branch ne $last_branch;
$state = 9;
} elsif($state == 8) {
@@ -898,7 +882,9 @@ # VERSION:1.96->1.96.2.1
commit() if $branch and $state != 11;
foreach my $git_index (values %index) {
- unlink($git_index);
+ if ($git_index ne '.git/index') {
+ unlink($git_index);
+ }
}
if (defined $orig_git_index) {
--
1.4.1.rc1.g1ef9
^ permalink raw reply related
* [PATCH] git-svn: SVN 1.1.x library compatibility
From: Eric Wong @ 2006-06-28 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virml4pqg.fsf@assigned-by-dhcp.cox.net>
Tested on a plain Ubuntu Hoary installation
using subversion 1.1.1-2ubuntu3
1.1.x issues I had to deal with:
* Avoid the noisy command-line client compatibility check if we
use the libraries.
* get_log() arguments differ (now using a nice wrapper from
Junio's suggestion)
* get_file() is picky about what kind of file handles it gets,
so I ended up redirecting STDOUT. I'm probably overflushing
my file handles, but that's the safest thing to do...
* BDB kept segfaulting on me during tests, so svnadmin will use FSFS
whenever we can.
* If somebody used an expanded CVS $Id$ line inside a file, then
propsetting it to use svn:keywords will cause the original CVS
$Id$ to be retained when asked for the original file. As far as
I can see, this is a server-side issue. We won't care in the
test anymore, as long as it's not expanded by SVN, a static
CVS $Id$ line is fine.
While we're at making ourselves more compatible, avoid grep
along with the -q flag, which is GNU-specific. (grep avoidance
tip from Junio, too)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > * get_log() arguments differ.
>
> Maybe you would want to have a single wrapper sub {} for this,
> instead of repeating it all over, perhaps like this:
>
> sub log_get {
> my ($SVN_LOG, @args) = @_;
> if ($SVN::CORE::VERSION ge '1.2.0') {
> splice(@args, 3, 0, 0);
> }
> $SVN_LOG->get_log(@args);
> }
I actually did it backwards (le) in case I want create something that
could take advantage of the limit arg for newer versions but degrade
gracefully for 1.1.x
contrib/git-svn/git-svn.perl | 30 +++++++++++++++++-----
contrib/git-svn/t/lib-git-svn.sh | 8 +++++-
contrib/git-svn/t/t0000-contrib-git-svn.sh | 14 +++++++++-
contrib/git-svn/t/t0001-contrib-git-svn-props.sh | 4 +--
4 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 08c3010..f026b24 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -134,7 +134,7 @@ usage(1) unless defined $cmd;
init_vars();
load_authors() if $_authors;
load_all_refs() if $_branch_all_refs;
-svn_compat_check();
+svn_compat_check() unless $_use_lib;
migration_check() unless $cmd =~ /^(?:init|rebuild|multi-init)$/;
$cmd{$cmd}->[0]->(@ARGV);
exit 0;
@@ -379,7 +379,8 @@ sub fetch_lib {
# performance sucks with it enabled, so it's much
# faster to fetch revision ranges instead of relying
# on the limiter.
- $SVN_LOG->get_log( '/'.$SVN_PATH, $min, $max, 0, 1, 1,
+ libsvn_get_log($SVN_LOG, '/'.$SVN_PATH,
+ $min, $max, 0, 1, 1,
sub {
my $log_msg;
if ($last_commit) {
@@ -924,7 +925,7 @@ sub graft_file_copy_lib {
$SVN::Error::handler = \&libsvn_skip_unknown_revs;
while (1) {
my $pool = SVN::Pool->new;
- $SVN_LOG->get_log( "/$path", $min, $max, 0, 1, 1,
+ libsvn_get_log($SVN_LOG, "/$path", $min, $max, 0, 1, 1,
sub {
libsvn_graft_file_copies($grafts, $tree_paths,
$path, @_);
@@ -2358,8 +2359,8 @@ sub libsvn_load {
return unless $_use_lib;
$_use_lib = eval {
require SVN::Core;
- if ($SVN::Core::VERSION lt '1.2.1') {
- die "Need SVN::Core 1.2.1 or better ",
+ if ($SVN::Core::VERSION lt '1.1.0') {
+ die "Need SVN::Core 1.1.0 or better ",
"(got $SVN::Core::VERSION) ",
"Falling back to command-line svn\n";
}
@@ -2392,9 +2393,15 @@ sub libsvn_get_file {
my $pool = SVN::Pool->new;
defined($pid = open3($in, $out, '>&STDERR',
qw/git-hash-object -w --stdin/)) or croak $!;
- my ($r, $props) = $SVN->get_file($f, $rev, $in, $pool);
+ # redirect STDOUT for SVN 1.1.x compatibility
+ open my $stdout, '>&', \*STDOUT or croak $!;
+ open STDOUT, '>&', $in or croak $!;
+ $| = 1; # not sure if this is necessary, better safe than sorry...
+ my ($r, $props) = $SVN->get_file($f, $rev, \*STDOUT, $pool);
$in->flush == 0 or croak $!;
+ open STDOUT, '>&', $stdout or croak $!;
close $in or croak $!;
+ close $stdout or croak $!;
$pool->clear;
chomp($hash = do { local $/; <$out> });
close $out or croak $!;
@@ -2566,7 +2573,8 @@ sub revisions_eq {
if ($_use_lib) {
# should be OK to use Pool here (r1 - r0) should be small
my $pool = SVN::Pool->new;
- $SVN->get_log("/$path", $r0, $r1, 0, 1, 1, sub {$nr++},$pool);
+ libsvn_get_log($SVN, "/$path", $r0, $r1,
+ 0, 1, 1, sub {$nr++}, $pool);
$pool->clear;
} else {
my ($url, undef) = repo_path_split($SVN_URL);
@@ -2606,6 +2614,14 @@ sub libsvn_find_parent_branch {
return undef;
}
+sub libsvn_get_log {
+ my ($ra, @args) = @_;
+ if ($SVN::Core::VERSION le '1.2.0') {
+ splice(@args, 3, 1);
+ }
+ $ra->get_log(@args);
+}
+
sub libsvn_new_tree {
if (my $log_entry = libsvn_find_parent_branch(@_)) {
return $log_entry;
diff --git a/contrib/git-svn/t/lib-git-svn.sh b/contrib/git-svn/t/lib-git-svn.sh
index 2843258..d7f972a 100644
--- a/contrib/git-svn/t/lib-git-svn.sh
+++ b/contrib/git-svn/t/lib-git-svn.sh
@@ -33,7 +33,13 @@ svnrepo=$PWD/svnrepo
set -e
-svnadmin create $svnrepo
+if svnadmin create --help | grep fs-type >/dev/null
+then
+ svnadmin create --fs-type fsfs "$svnrepo"
+else
+ svnadmin create "$svnrepo"
+fi
+
svnrepo="file://$svnrepo/test-git-svn"
diff --git a/contrib/git-svn/t/t0000-contrib-git-svn.sh b/contrib/git-svn/t/t0000-contrib-git-svn.sh
index 443d518..b482bb6 100644
--- a/contrib/git-svn/t/t0000-contrib-git-svn.sh
+++ b/contrib/git-svn/t/t0000-contrib-git-svn.sh
@@ -5,6 +5,16 @@ #
test_description='git-svn tests'
GIT_SVN_LC_ALL=$LC_ALL
+
+case "$LC_ALL" in
+*.UTF-8)
+ have_utf8=t
+ ;;
+*)
+ have_utf8=
+ ;;
+esac
+
. ./lib-git-svn.sh
mkdir import
@@ -173,7 +183,7 @@ then
fi
-if test -n "$GIT_SVN_LC_ALL" && echo $GIT_SVN_LC_ALL | grep -q '\.UTF-8$'
+if test "$have_utf8" = t
then
name="commit with UTF-8 message: locale: $GIT_SVN_LC_ALL"
echo '# hello' >> exec-2.sh
@@ -203,7 +213,7 @@ fi
name='check imported tree checksums expected tree checksums'
rm -f expected
-if test -n "$GIT_SVN_LC_ALL" && echo $GIT_SVN_LC_ALL | grep -q '\.UTF-8$'
+if test "$have_utf8" = t
then
echo tree f735671b89a7eb30cab1d8597de35bd4271ab813 > expected
fi
diff --git a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
index 54e0ed7..a5a235f 100644
--- a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
+++ b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
@@ -21,8 +21,8 @@ a_empty_crlf=
cd import
cat >> kw.c <<\EOF
-/* Make it look like somebody copied a file from CVS into SVN: */
-/* $Id: kw.c,v 1.1.1.1 1994/03/06 00:00:00 eric Exp $ */
+/* Somebody prematurely put a keyword into this file */
+/* $Id$ */
EOF
printf "Hello\r\nWorld\r\n" > crlf
--
1.4.1.rc1.gc7c5
^ permalink raw reply related
* Re: Quick merge status updates.
From: Pavel Roskin @ 2006-06-28 10:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j3164xd.fsf@assigned-by-dhcp.cox.net>
On Wed, 2006-06-28 at 01:49 -0700, Junio C Hamano wrote:
> I suspect this is either FC perl-dev package is broken (I doubt
> it) or your installation procedure is pecurilar (much more
> likely). I pass the same set of prefix, bindir and friends to
> "make" and "make install" and do not see the problem.
I think my Perl 5.8.8 is "too new". "man perlfunc" says about "use":
"Imports some semantics into the current package from the named module,
generally by aliasing certain subroutine or variable names into your
package. It is exactly equivalent to
BEGIN { require Module; import Module LIST; }
except that Module must be a bareword."
I think the BEGIN block has priority over other statements. My solution
was to put the @INC change in the BEGIN block as well.
This patch is working for me:
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index e8fad02..1b23fa1 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -5,7 +5,7 @@ #
# Read .git/FETCH_HEAD and make a human readable merge message
# by grouping branches and tags together to form a single line.
-unshift @INC, '@@INSTLIBDIR@@';
+BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
use strict;
use Git;
use Error qw(:try);
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: CFT: merge-recursive in C (updated)
From: Johannes Schindelin @ 2006-06-28 10:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <81b0412b0606280234x7d07fbbck7887b5214d98bf91@mail.gmail.com>
Hi,
On Wed, 28 Jun 2006, Alex Riesen wrote:
> On 6/28/06, Alex Riesen <fork0@t-online.de> wrote:
> > Johannes Schindelin, Tue, Jun 27, 2006 18:42:51 +0200:
> > > > - use a pipe to "git-update-index --index-info" instead of using command
> > > > line
>
> ...and to take it a step further, a patch (0002) to avoid too many calls to
> git-write-tree and to git-update-index.
... and introduces a lot more lines doing debug output.
However, the change is good, but I would not call it "FILE *fp". IMHO
"FILE *update_index_pipe" would explain better what you do there.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] quote.c: silence compiler warnings from EMIT macro
From: Junio C Hamano @ 2006-06-28 10:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060628055923.GA6071@coredump.intra.peff.net>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] rebase: check for errors from git-commit
From: Junio C Hamano @ 2006-06-28 9:56 UTC (permalink / raw)
To: git
In-Reply-To: <20060628095454.GA23948@soma>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>>
>> > Junio C Hamano <junkio@cox.net> wrote:
>> >
>> >> Anticipating failure from "git-commit" is the right thing to do,
>> >> but this is a "Now what?" situation. What is the expected
>> >> course of action to recover from this for the end user, and how
>> >> can we phrase the error message to help that process?
>> >
>> > I would expect git-commit to show the correct error message (or the
>> > pre-commit hook), die "$RESOLVEMSG" might be a better option, though.
>>
>> It would say 'resolve conflicts, mark them with update-index as
>> necessary, and say git-commit' or somesuch. I am not sure you
>> would want the user to make a commit like suggested -- instead
>> you would want him to say 'git rebase --continue' wouldn't you?
>
> Actually RESOLVEMSG in git-rebase just tells the user about the
> --continue, --skip, --abort options.
Yup, so telling the user to disregard what commit might say (but
do not hide it by redirecting 2>/dev/null, please) and dying
with "$RESOLVEMSG" might be a better way.
^ permalink raw reply
* Re: [PATCH 1/2] rebase: check for errors from git-commit
From: Eric Wong @ 2006-06-28 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveql38zr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >
> >> Anticipating failure from "git-commit" is the right thing to do,
> >> but this is a "Now what?" situation. What is the expected
> >> course of action to recover from this for the end user, and how
> >> can we phrase the error message to help that process?
> >
> > I would expect git-commit to show the correct error message (or the
> > pre-commit hook), die "$RESOLVEMSG" might be a better option, though.
>
> It would say 'resolve conflicts, mark them with update-index as
> necessary, and say git-commit' or somesuch. I am not sure you
> would want the user to make a commit like suggested -- instead
> you would want him to say 'git rebase --continue' wouldn't you?
Actually RESOLVEMSG in git-rebase just tells the user about the
--continue, --skip, --abort options.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git.c: Re-introduce sane error messages on missing commands.
From: Junio C Hamano @ 2006-06-28 9:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0606281118330.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Try this:
>
> $ mkdir 5
> $ cd 5
> $ git-init-db
> $ rm .git/config # yes, really.
> $ git abc
Thanks for trying to help, but not really.
: gitster; mkdir 5
: gitster; cd 5
: gitster; git-init-db
defaulting to local storage area
: gitster; rm .git/config
: gitster; ~/git-master/bin/git abc
git: 'abc' is not a git-command
The most commonly used git commands are:
add Add files to the index file
apply Apply patch on a git index file and a work
...
tag Create a tag object signed with GPG
verify-tag Check the GPG signature of tag
(use 'git help -a' to get a list of all installed git commands)
: gitster; ~/git-master/bin/git --version
git version 1.4.1.rc1.g8096
: gitster; ls -ld ~/.gitrc ~/.gitconfig ~/.git-config
: gitster; ls -ld ~/.gitrc ~/.gitconfig ~/.git-config
ls: /home/junio/.gitrc: No such file or directory
ls: /home/junio/.gitconfig: No such file or directory
ls: /home/junio/.git-config: No such file or directory
: gitster; : confused...
^ permalink raw reply
* Re: [PATCH 1/2] rebase: check for errors from git-commit
From: Junio C Hamano @ 2006-06-28 9:49 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060628093322.GA29036@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> Anticipating failure from "git-commit" is the right thing to do,
>> but this is a "Now what?" situation. What is the expected
>> course of action to recover from this for the end user, and how
>> can we phrase the error message to help that process?
>
> I would expect git-commit to show the correct error message (or the
> pre-commit hook), die "$RESOLVEMSG" might be a better option, though.
It would say 'resolve conflicts, mark them with update-index as
necessary, and say git-commit' or somesuch. I am not sure you
would want the user to make a commit like suggested -- instead
you would want him to say 'git rebase --continue' wouldn't you?
^ permalink raw reply
* Re: [PATCH 1/2] rebase: check for errors from git-commit
From: Junio C Hamano @ 2006-06-28 9:25 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11514858662929-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I've grown used to having 'set -e' at the beginning of my shell
> scripts. IMHO it'd be a good idea to start moving towards this
> eventually (even though shell scripts seem to be getting phased-out
> somewhat).
>
> git-rebase.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 9ad1c44..47c8e8f 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -59,8 +59,8 @@ continue_merge () {
>
> if test -n "`git-diff-index HEAD`"
> then
> + git-commit -C "`cat $dotest/current`" || die 'Commit failed'
> printf "Committed: %0${prec}d" $msgnum
> - git-commit -C "`cat $dotest/current`"
Anticipating failure from "git-commit" is the right thing to do,
but this is a "Now what?" situation. What is the expected
course of action to recover from this for the end user, and how
can we phrase the error message to help that process?
^ permalink raw reply
* Re: CFT: merge-recursive in C
From: Junio C Hamano @ 2006-06-28 9:22 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: Alex Riesen, git
In-Reply-To: <20060628063747.GA983@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> Hello Alex,
>
>> +// does not belong here
> Some C compiler (e.g. Sun Forte) don't like C++-style comments.
Heh, I said something like that last year and was scolded by
Linus who responded "what century are you living in?" ;-).
^ permalink raw reply
* Re: [PATCH] git.c: Re-introduce sane error messages on missing commands.
From: Johannes Schindelin @ 2006-06-28 9:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <44A23A38.3090206@op5.se>
Hi,
On Wed, 28 Jun 2006, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > Andreas Ericsson <ae@op5.se> writes:
> >
> >
> > > Somewhere in the alias handling git turned hostile on fat fingers:
> > >
> > > $ git showbranch
> > > Failed to run command '': Is a directory
> >
> >
> > Does not happen here (nor on Cygwin 1.4.1.rc1). Care to help
> > reproducing it?
Try this:
$ mkdir 5
$ cd 5
$ git-init-db
$ rm .git/config # yes, really.
$ git abc
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix a mixed declarations and code warning
From: Timo Hirvonen @ 2006-06-28 9:15 UTC (permalink / raw)
To: junkio; +Cc: git
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
NOTE: This is for the pu branch
exec_cmd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index f2133ec..62f51fc 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -98,8 +98,8 @@ int execv_git_cmd(const char **argv)
argv[0] = git_command;
if (getenv("GIT_TRACE")) {
- fputs("trace: exec:", stderr);
const char **p = argv;
+ fputs("trace: exec:", stderr);
while (*p) {
fputc(' ', stderr);
sq_quote_print(stderr, *p);
--
1.4.1.rc1.g1ef9
^ permalink raw reply related
* Re: Quick merge status updates.
From: Johannes Schindelin @ 2006-06-28 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, pasky
In-Reply-To: <7vy7vh4q8w.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 28 Jun 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > on my iBook, make in pu outputs:
> >
> > GIT_VERSION = 1.4.1.rc1.gf5d3
> > * new build flags or prefix
> > (cd perl && /usr/bin/perl Makefile.PL \
> > PREFIX='/Users/gene099' \
> > DEFINE=' -I/sw/include -DSHA1_HEADER='\''<openssl/sha.h>'\''
> > -DNO_STRCASESTR -DNO_STRLCPY -DGIT_VERSION='\''"1.4.1.rc1.gf5d3"'\''' \
> > LIBS=' -L/sw/lib -lz -liconv -lcrypto -lssl')
> > Can't locate Devel/PPPort.pm in @INC (@INC contains:
> > /System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin
> > /Library/Perl /Library/Perl /Network/Library/Perl/darwin
> > /Network/Library/Perl /Network/Library/Perl .) at Makefile.PL line 29.
> > BEGIN failed--compilation aborted at Makefile.PL line 29.
> > make: *** [perl/Makefile] Error 2
> >
> > FWIW all Perl scripts in git, except git-send-email, work here.
>
> I suspect git-fmt-merge-msg doesn't, and perhaps git-mv.
Last time I checked, git-mv worked (couple of weeks ago). And if I am not
mistaken, git-fmt-merge-msg is needed when git-pull does not fast forward?
I definitely successfully merged on my iBook, IIRC last time was last
week.
BTW: Devel/PPPort.pm is introduced by this line in perl/Git.xs:
> #include "ppport.h"
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] rebase: get rid of outdated MRESOLVEMSG
From: Eric Wong @ 2006-06-28 9:11 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
In-Reply-To: <11514858662929-git-send-email-normalperson@yhbt.net>
There was a time when rebase --skip didn't work when used with
--merge, but that is no more so we don't need that message
anymore.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-rebase.sh | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 47c8e8f..16fe6e0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -34,11 +34,6 @@ When you have resolved this problem run
If you would prefer to skip this patch, instead run \"git rebase --skip\".
To restore the original branch and stop rebasing run \"git rebase --abort\".
"
-
-MRESOLVEMSG="
-When you have resolved this problem run \"git rebase --continue\".
-To restore the original branch and stop rebasing run \"git rebase --abort\".
-"
unset newbase
strategy=recursive
do_merge=
@@ -54,7 +49,7 @@ continue_merge () {
then
echo "You still have unmerged paths in your index"
echo "did you forget update-index?"
- die "$MRESOLVEMSG"
+ die "$RESOLVEMSG"
fi
if test -n "`git-diff-index HEAD`"
@@ -87,11 +82,11 @@ call_merge () {
;;
1)
test -d "$GIT_DIR/rr-cache" && git-rerere
- die "$MRESOLVEMSG"
+ die "$RESOLVEMSG"
;;
2)
echo "Strategy: $rv $strategy failed, try another" 1>&2
- die "$MRESOLVEMSG"
+ die "$RESOLVEMSG"
;;
*)
die "Unknown exit code ($rv) from command:" \
--
1.4.1.rc1.g3cc8
^ permalink raw reply related
* [PATCH 1/2] rebase: check for errors from git-commit
From: Eric Wong @ 2006-06-28 9:11 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
commit does not always succeed, so we'll have to check for
it in the absence of set -e. This fixes a regression
introduced in 9e4bc7dd1bb9d92491c475cec55147fa0b3f954d
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
I've grown used to having 'set -e' at the beginning of my shell
scripts. IMHO it'd be a good idea to start moving towards this
eventually (even though shell scripts seem to be getting phased-out
somewhat).
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 9ad1c44..47c8e8f 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -59,8 +59,8 @@ continue_merge () {
if test -n "`git-diff-index HEAD`"
then
+ git-commit -C "`cat $dotest/current`" || die 'Commit failed'
printf "Committed: %0${prec}d" $msgnum
- git-commit -C "`cat $dotest/current`"
else
printf "Already applied: %0${prec}d" $msgnum
fi
--
1.4.1.rc1.g3cc8
^ 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