Rebasing merge to 1.7.8.2
Johannes Schindelin
I just performed a rebasing merge with the usual fixups afterwards. Please
find the result on the 'devel' branch of git://github.com/msysgit/git.
The tests are still running in my VM (it's now around t4015) but there are
two issues still: I have rare (read: non-repeatable) failures with t0025
and t0202 does not work at all.
In case somebody chose as resolution to stop watching TV and help the
msysGit effort instead, here is a good opportunity to do so! :-)
Ciao,
Johannes
Sebastian Schuberth
> The tests are still running in my VM (it's now around t4015) but there are
> two issues still: I have rare (read: non-repeatable) failures with t0025
> and t0202 does not work at all.
BTW, are you using "prove" for testing? I've recent enabled it again as
it was broken due to some Perl dependencies, and it speeds up testing a lot!
--
Sebastian Schuberth
Sebastian Schuberth
> The tests are still running in my VM (it's now around t4015) but there are
> two issues still: I have rare (read: non-repeatable) failures with t0025
> and t0202 does not work at all.
The problem with t0202 seems to be that /git/perl/Git/I18N.pm is in none
of the Perl module search paths. I'm not familiar enough with Perl to
say what's the best way to fix this.
--
Sebastian Schuberth
Sebastian Schuberth
> BTW, are you using "prove" for testing? I've recent enabled it again as
> it was broken due to some Perl dependencies, and it speeds up testing a
> lot!
And I have *way* more test failing than you, for example all git-svn
tests, as it seems. I wonder whether this is related to me using the
Perl-based "prove" (and git-svn also being Perl), while you're probably
not using it.
--
Sebastian Schuberth
Pat Thoyts
I believe we all use /share/msysGit/run-tests.sh which uses make to
run multiple parallel tests and even more usefully keeps the noise
level down so you can see the failed tests at the end easily.
Sebastian Schuberth
>>> BTW, are you using "prove" for testing? I've recent enabled it again as
>>> it was broken due to some Perl dependencies, and it speeds up testing a
>>> lot!
>>
>> And I have *way* more test failing than you, for example all git-svn tests,
>> as it seems. I wonder whether this is related to me using the Perl-based
>> "prove" (and git-svn also being Perl), while you're probably not using it.
>
> I believe we all use /share/msysGit/run-tests.sh which uses make to
> run multiple parallel tests and even more usefully keeps the noise
> level down so you can see the failed tests at the end easily.
Thanks for reminding me of this script. I have far less tests failing with this, in particular my output is:
These tests failed: t0202-gettext-perl t5516-fetch-push t7406-submodule-update t7407-submodule-foreach
Unfinished tests: t9200-git-cvsexportcommit
--
Sebastian Schuberth
Pat Thoyts
The last couple of releases have had no failures except for the t9200.
However, I have found that it is often useful to check each reported
failing file with 'cd t && make tNNNN' just to check it wasn't
something to do with the parallel make or timing. I suspect the t74*
ones are transient and if you retry just those they might pass.
Whether that means there remains some real issue or if it is truly a
side effect of the parallel make I don't know.
Sebastian Schuberth
>> These tests failed: t0202-gettext-perl t5516-fetch-push t7406-submodule-update t7407-submodule-foreach
>> Unfinished tests: t9200-git-cvsexportcommit
>
> The last couple of releases have had no failures except for the t9200.
> However, I have found that it is often useful to check each reported
> failing file with 'cd t && make tNNNN' just to check it wasn't
> something to do with the parallel make or timing. I suspect the t74*
> ones are transient and if you retry just those they might pass.
> Whether that means there remains some real issue or if it is truly a
> side effect of the parallel make I don't know.
I ran the failed tests separately and they fail for real. However, it
seems only tests that use test_i18ncmp fail, which in turn might be
related to the missing I18N.pm Perl module that I've mentioned in my
other mail.
--
Sebastian Schuberth
Johannes Schindelin
Ah, "prove" is for testing! I did not know that. Is it easy to integrate
it into /share/msysGit/run-tests.sh?
Thanks!
Dscho
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
> Ah, "prove" is for testing! I did not know that. Is it easy to integrate
> it into /share/msysGit/run-tests.sh?
I don't know, but I think it makes no sense. "prove" is basically is a
wrapper to run tests in parallel (see t/README for more), and
run-tests.sh serves the same purpose. So to me, they're alternatives
with each its own features, and not something we should combine.
--
Sebastian Schuberth
Johannes Schindelin
On Fri, 6 Jan 2012, Sebastian Schuberth wrote:
Yes, my workflow is the same as Pat described: call run-tests.sh, do
something meaningful (read: different) for half a day (or in case of
yesterday, night), and then run the tests individually. Although I use "sh
tNNNN-* -i -v" to make sure that it stops when a test fails, and that I
have the full output. If that does not reveal what is the reason, I
usually call "sh -x tNNNN-* -i -v" which lists the shell commands that are
about to run, too.
In many cases, this makes the error go away.
Ciao,
Dscho
P.S.: I did not have a chance yet to look at the final result of the test
run.
Johannes Schindelin
On Fri, 6 Jan 2012, Sebastian Schuberth wrote:
Well, for me, run-tests is just the way it runs tests. And if prove is
faster than (cd /git/t && make -j5) then I'll be happy if run-tests uses
prove rather than make.
Ciao,
Dscho
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
>> > Ah, "prove" is for testing! I did not know that. Is it easy to integrate
>> > it into /share/msysGit/run-tests.sh?
>>
>> I don't know, but I think it makes no sense. "prove" is basically is a
>> wrapper to run tests in parallel (see t/README for more), and
>> run-tests.sh serves the same purpose. So to me, they're alternatives
>> with each its own features, and not something we should combine.
>
> Well, for me, run-tests is just the way it runs tests. And if prove is
> faster than (cd /git/t && make -j5) then I'll be happy if run-tests uses
> prove rather than make.
But why then not just use prove instead of tun-tests? prove already
has pretty nice formatted output, so there's almost nothing to do for
a run-tests script using prove. I guess you should just try out prove
before we go on with the discussion ;-)
--
Sebastian Schuberth
Johannes Schindelin
On Fri, 6 Jan 2012, Sebastian Schuberth wrote:
I just pushed a fix to our 'devel' branch:
https://github.com/msysgit/git/commit/c0e2b3c8f4c254025ad9cfb69f775604f5787c3d
The problem was that 5e9637c6 forgot to support non-MakeMaker-enabled
systems.
Ciao,
Dscho
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
>> > The tests are still running in my VM (it's now around t4015) but there are
>> > two issues still: I have rare (read: non-repeatable) failures with t0025
>> > and t0202 does not work at all.
>>
>> The problem with t0202 seems to be that /git/perl/Git/I18N.pm is in none of
>> the Perl module search paths. I'm not familiar enough with Perl to say what's
>> the best way to fix this.
>
> I just pushed a fix to our 'devel' branch:
>
> https://github.com/msysgit/git/commit/c0e2b3c8f4c254025ad9cfb69f775604f5787c3d
>
> The problem was that 5e9637c6 forgot to support non-MakeMaker-enabled
> systems.
Thanks! I can confirm this fixes t0202 for me.
--
Sebastian Schuberth
Johannes Schindelin
On Fri, 6 Jan 2012, Sebastian Schuberth wrote:
Okay, I did that. --color does not work, but otherwise: very nice! I would
still see a point, though, in replacing the contents of run-tests by the
one-liner "cd /git/t && prove --timer --jobs 15 --color ./t[0-9]*.sh" so
that I do not have to remember any options and do not have to retrain my
fingers to type anything else than /sh<Tab>ms<Tab>ru<Tab><Return> :-)
Ciao,
Dscho
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
>> But why then not just use prove instead of tun-tests? prove already
>> has pretty nice formatted output, so there's almost nothing to do for
>> a run-tests script using prove. I guess you should just try out prove
>> before we go on with the discussion ;-)
>
> Okay, I did that. --color does not work, but otherwise: very nice! I would
> still see a point, though, in replacing the contents of run-tests by the
> one-liner "cd /git/t && prove --timer --jobs 15 --color ./t[0-9]*.sh" so
> that I do not have to remember any options and do not have to retrain my
> fingers to type anything else than /sh<Tab>ms<Tab>ru<Tab><Return> :-)
Right. On the other hand prove does not give you such a nice summary
of failed / uncompleted tests like run-tests does.
Oh, and did for you also more test fail when using prove than when
using run-tests? If so, I believe we should leave run-tests as-is
until we've figured out why that is.
--
Sebastian Schuberth
Johannes Schindelin
On Fri, 6 Jan 2012, Johannes Schindelin wrote:
> [prove] --color does not work, but otherwise: very nice!
Correction: --color _does_ work, it just does not color the "ok" green as
run-tests still does. But that is just bikeshedding :-)
I'd be in favor of replacing the custom run-tests with that one-liner I
mentioned earlier: one thing less to maintain. Pat? Are you d'accord?
Ciao,
Dscho
Johannes Schindelin
On Fri, 6 Jan 2012, Sebastian Schuberth wrote:
> On Fri, Jan 6, 2012 at 21:18, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>
> >> But why then not just use prove instead of tun-tests? prove already
> >> has pretty nice formatted output, so there's almost nothing to do for
> >> a run-tests script using prove. I guess you should just try out prove
> >> before we go on with the discussion ;-)
> >
> > Okay, I did that. --color does not work, but otherwise: very nice! I
> > would still see a point, though, in replacing the contents of
> > run-tests by the one-liner "cd /git/t && prove --timer --jobs 15
> > --color ./t[0-9]*.sh" so that I do not have to remember any options
> > and do not have to retrain my fingers to type anything else than
> > /sh<Tab>ms<Tab>ru<Tab><Return> :-)
>
> Right. On the other hand prove does not give you such a nice summary of
> failed / uncompleted tests like run-tests does.
Hmm. I thought we can just do a
(cd test-results &&
grep -l -e "broken [^0]" -e "failed [^0]" *.counts |
sed 's/.counts$//')
But 1) there are also remnants of previous runs, and 2) it seems that the
tests called by prove do not store their results there.
Maybe we can do something with --state=hot,save and parse .prove?
> Oh, and did for you also more test fail when using prove than when using
> run-tests? If so, I believe we should leave run-tests as-is until we've
> figured out why that is.
I have to admit that I forgot about that. Yes, I will try to find out what
is happening.
One thing I saw that is real nice is that that intermittent failure t0025
was labeled as "Dubious, test returned 1 (stat 256, 0x100)". I still have
to find out what that means, but that's more information than I had before
;-)
Ciao,
Dscho
Sebastian Schuberth
> I just pushed a fix to our 'devel' branch:
>
> https://github.com/msysgit/git/commit/c0e2b3c8f4c254025ad9cfb69f775604f5787c3d
>
> The problem was that 5e9637c6 forgot to support non-MakeMaker-enabled
> systems.
And I've just added Git/I18N.pm also to .gitignore (in msysgit.git):
https://github.com/msysgit/msysgit/commit/5d887ee7c8586bc6dc696b37ba58b3ce4916ed24
--
Sebastian Schuberth
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
> Maybe we can do something with --state=hot,save and parse .prove?
I just looked a prove's summary again. Although it's not as compact as
run-tests', it's good enough for me.
>> Oh, and did for you also more test fail when using prove than when using
>> run-tests? If so, I believe we should leave run-tests as-is until we've
>> figured out why that is.
>
> I have to admit that I forgot about that. Yes, I will try to find out what
> is happening.
>
> One thing I saw that is real nice is that that intermittent failure t0025
> was labeled as "Dubious, test returned 1 (stat 256, 0x100)". I still have
> to find out what that means, but that's more information than I had before
> ;-)
Yeah, the git-svn tests I see failing with prove are also "Dubious,
test returned 1 (stat 256, 0x100)".
--
Sebastian Schuberth
Johannes Schindelin
On Fri, 6 Jan 2012, Sebastian Schuberth wrote:
Good catch!
Thanks,
Dscho
Pat Thoyts
I'll try it out and see. I really like run-tests for its summary. I
actually use it on unix too. But if we switch to prove I think
changing run-tests to call it properly will be the right way to go.
Ævar Arnfjörð Bjarmason
> systems.
Ah, sorry about that. But why don't these systems support MakeMaker in
the first place?
I remember being told that at one point and the reason being something
that could probably be fixed now that we depend on perl 5.8.
Sebastian Schuberth
> I just performed a rebasing merge with the usual fixups afterwards. Please
> find the result on the 'devel' branch of git://github.com/msysgit/git.
Now that upstream Git 1.7.8.3 is out, would you mind doing other
rebasing merge onto that?
--
Sebastian Schuberth
Johannes Schindelin
Done.
BTW I think that the problem with t7407 at least is due to the usage of
the '$path' variable in submodule foreach, which does not work since the
environment variable names in Windows are case-insensitive and $path is
mistaken for $PATH.
I recall that we had this issue before, but I don't recall the resolution.
Anyone?
Ciao,
Johannes
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
>> Now that upstream Git 1.7.8.3 is out, would you mind doing other rebasing
>> merge onto that?
>
> Done.
Thanks!
> BTW I think that the problem with t7407 at least is due to the usage of
> the '$path' variable in submodule foreach, which does not work since the
> environment variable names in Windows are case-insensitive and $path is
> mistaken for $PATH.
>
> I recall that we had this issue before, but I don't recall the resolution.
>
> Anyone?
I believe this has already been fixed by Karsten:
http://permalink.gmane.org/gmane.comp.version-control.msysgit/14048
Unfortunately, I'm unable to apply his path due to wrapped lines and
git am not recognizing the patch format.
Karsten, do you have this patch applied in a Git fork?
--
Sebastian Schuberth
karste...@dcon.de
http://repo.or.cz/w/git/mingw/4msysgit/kblees.git/kb/unicode-v13
However, t7407 fails for me too (with the unicode-v13 branch rebased to current devel), the $PATH gets indeed mangled into the 'actual' file.
Btw, the case-sensitive-before-case-insensitive mingw_getenv was to fix git-sh-i18n--envsubst, and it only works with environment variables passed from MSYS programs to git. The MSYS startup code eliminates duplicate variables if it is called by non-MSYS programs. I.e. passing $path/$PATH from MSYS-bash/perl to MSYS-bash/perl works, and MSYS-bash/perl to git works, too (due to case-sensitive-before-case-insensitive lookup), but git to MSYS-bash/perl does _not_ work.
hope that helps,
Karsten
karste...@dcon.de
> > the '$path' variable in submodule foreach, which does not work since the
> > environment variable names in Windows are case-insensitive and $path is
> > mistaken for $PATH.
> >
> > I recall that we had this issue before, but I don't recall the resolution.
> >
> > Anyone?
The t7407 failures are caused by the git-sh-i18n.sh changes in 5e9637c6 "i18n: add infrastructure for translating Git with gettext".
Git-sh-i18n.sh now detects gettext.sh on the path and uses this instead of git-sh-i18n--envsubst.exe. Gettext.sh calls run-of-the-mill MinGW gettext.exe / envsubst.exe programs based on MSVCRT's getenv implementation, which does _not_ support case-sensitive environment variables.
I've described this here [1], along with an alternate solution to the $path/$PATH problem, but got no feedback so far...
Cheers,
Karsten
[1] http://thread.gmane.org/gmane.comp.version-control.git/175094/focus=182857
Johannes Schindelin
In [1] you described a...
Small solution (only affects gettext): in git-submodule.sh,
replace all 'eval_gettext...$path' with 'modulepath=$path
eval_gettext...$modulepath'
I do not quite see where you want to go there. Is it easy enough to come
up with a small patch?
Ciao,
Dscho
karste...@dcon.de
This fixes t7407, but 'git submodule foreach <command>' is still unusable on Windows if <command> 'leaves' the MSYS world (i.e. is not a bash/perl script).
The _really_ big solution would be to rename all git-submodule.sh variables that might cross process boundaries to something like GIT_MODULE_* (similar as in git-filter-branch).
Ciao,
Karsten
---
From d6f6c76aeb52127c22e6942a6c7018faf1744f06 Mon Sep 17 00:00:00 2001
From: Karsten Blees <bl...@dcon.de>
Date: Mon, 9 Jan 2012 19:16:30 +0100
Subject: [PATCH] Windows/i18n: rename $path to prevent clashes with $PATH
Environment variables on Windows are case-insensitive. Rename '$path' in
all calls to eval_gettext to $modulepath so that it is not mistakenly
expanded to the value of the $PATH variable.
Signed-off-by: Karsten Blees <bl...@dcon.de>
---
git-submodule.sh | 52 ++++++++++++++++++++++++++--------------------------
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index de06bc1..0a37d70 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -105,7 +105,7 @@ module_name()
name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
test -z "$name" &&
- die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$path'")"
+ die "$(modulepath=$path eval_gettext "No submodule mapping found in .gitmodules for path '\$modulepath'")"
echo "$name"
}
@@ -169,7 +169,7 @@ module_clone()
else
git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
fi ||
- die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
+ die "$(modulepath=$path eval_gettext "Clone of '\$url' into submodule path '\$modulepath' failed")"
fi
}
@@ -260,13 +260,13 @@ cmd_add()
s|/*$||
')
git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
- die "$(eval_gettext "'\$path' already exists in the index")"
+ die "$(modulepath=$path eval_gettext "'\$modulepath' already exists in the index")"
if test -z "$force" && ! git add --dry-run --ignore-missing "$path" > /dev/null 2>&1
then
cat >&2 <<EOF
The following path is ignored by one of your .gitignore files:
-$(eval_gettextln $path)
+$(modulepath=$path eval_gettextln $modulepath)
Use -f if you really want to add it.
EOF
exit 1
@@ -277,9 +277,9 @@ EOF
then
if test -d "$path"/.git -o -f "$path"/.git
then
- eval_gettextln "Adding existing repo at '\$path' to the index"
+ modulepath=$path eval_gettextln "Adding existing repo at '\$modulepath' to the index"
else
- die "$(eval_gettext "'\$path' already exists and is not a valid git repo")"
+ die "$(modulepath=$path eval_gettext "'\$modulepath' already exists and is not a valid git repo")"
fi
else
@@ -293,17 +293,17 @@ EOF
'') git checkout -f -q ;;
?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
esac
- ) || die "$(eval_gettext "Unable to checkout submodule '\$path'")"
+ ) || die "$(modulepath=$path eval_gettext "Unable to checkout submodule '\$modulepath'")"
fi
git config submodule."$path".url "$realrepo"
git add $force "$path" ||
- die "$(eval_gettext "Failed to add submodule '\$path'")"
+ die "$(modulepath=$path eval_gettext "Failed to add submodule '\$modulepath'")"
git config -f .gitmodules submodule."$path".path "$path" &&
git config -f .gitmodules submodule."$path".url "$repo" &&
git add --force .gitmodules ||
- die "$(eval_gettext "Failed to register submodule '\$path'")"
+ die "$(modulepath=$path eval_gettext "Failed to register submodule '\$modulepath'")"
}
#
@@ -345,7 +345,7 @@ cmd_foreach()
do
if test -e "$path"/.git
then
- say "$(eval_gettext "Entering '\$prefix\$path'")"
+ say "$(modulepath=$path eval_gettext "Entering '\$prefix\$modulepath'")"
name=$(module_name "$path")
(
prefix="$prefix$path/"
@@ -357,7 +357,7 @@ cmd_foreach()
cmd_foreach "--recursive" "$@"
fi
) <&3 3<&- ||
- die "$(eval_gettext "Stopping at '\$path'; script returned non-zero status.")"
+ die "$(modulepath=$path eval_gettext "Stopping at '\$modulepath'; script returned non-zero status.")"
fi
done
}
@@ -399,7 +399,7 @@ cmd_init()
then
url=$(git config -f .gitmodules submodule."$name".url)
test -z "$url" &&
- die "$(eval_gettext "No url found for submodule path '\$path' in .gitmodules")"
+ die "$(modulepath=$path eval_gettext "No url found for submodule path '\$modulepath' in .gitmodules")"
# Possibly a url relative to parent
case "$url" in
@@ -408,7 +408,7 @@ cmd_init()
;;
esac
git config submodule."$name".url "$url" ||
- die "$(eval_gettext "Failed to register url for submodule path '\$path'")"
+ die "$(modulepath=$path eval_gettext "Failed to register url for submodule path '\$modulepath'")"
fi
# Copy "update" setting when it is not set yet
@@ -416,9 +416,9 @@ cmd_init()
test -z "$upd" ||
test -n "$(git config submodule."$name".update)" ||
git config submodule."$name".update "$upd" ||
- die "$(eval_gettext "Failed to register update mode for submodule path '\$path'")"
+ die "$(modulepath=$path eval_gettext "Failed to register update mode for submodule path '\$modulepath'")"
- say "$(eval_gettext "Submodule '\$name' (\$url) registered for path '\$path'")"
+ say "$(modulepath=$path eval_gettext "Submodule '\$name' (\$url) registered for path '\$modulepath'")"
done
}
@@ -517,7 +517,7 @@ cmd_update()
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
- say "$(eval_gettext "Submodule path '\$path' not initialized
+ say "$(modulepath=$path eval_gettext "Submodule path '\$modulepath' not initialized
Maybe you want to use 'update --init'?")"
continue
fi
@@ -530,7 +530,7 @@ Maybe you want to use 'update --init'?")"
else
subsha1=$(clear_local_git_env; cd "$path" &&
git rev-parse --verify HEAD) ||
- die "$(eval_gettext "Unable to find current revision in submodule path '\$path'")"
+ die "$(modulepath=$path eval_gettext "Unable to find current revision in submodule path '\$modulepath'")"
fi
if test "$subsha1" != "$sha1"
@@ -549,7 +549,7 @@ Maybe you want to use 'update --init'?")"
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
- die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
+ die "$(modulepath=$path eval_gettext "Unable to fetch in submodule path '\$modulepath'")"
fi
# Is this something we just cloned?
@@ -563,20 +563,20 @@ Maybe you want to use 'update --init'?")"
case "$update_module" in
rebase)
command="git rebase"
- die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$path'")"
- say_msg="$(eval_gettext "Submodule path '\$path': rebased into '\$sha1'")"
+ die_msg="$(modulepath=$path eval_gettext "Unable to rebase '\$sha1' in submodule path '\$modulepath'")"
+ say_msg="$(modulepath=$path eval_gettext "Submodule path '\$modulepath': rebased into '\$sha1'")"
must_die_on_failure=yes
;;
merge)
command="git merge"
- die_msg="$(eval_gettext "Unable to merge '\$sha1' in submodule path '\$path'")"
- say_msg="$(eval_gettext "Submodule path '\$path': merged in '\$sha1'")"
+ die_msg="$(modulepath=$path eval_gettext "Unable to merge '\$sha1' in submodule path '\$modulepath'")"
+ say_msg="$(modulepath=$path eval_gettext "Submodule path '\$modulepath': merged in '\$sha1'")"
must_die_on_failure=yes
;;
*)
command="git checkout $subforce -q"
- die_msg="$(eval_gettext "Unable to checkout '\$sha1' in submodule path '\$path'")"
- say_msg="$(eval_gettext "Submodule path '\$path': checked out '\$sha1'")"
+ die_msg="$(modulepath=$path eval_gettext "Unable to checkout '\$sha1' in submodule path '\$modulepath'")"
+ say_msg="$(modulepath=$path eval_gettext "Submodule path '\$modulepath': checked out '\$sha1'")"
;;
esac
@@ -598,7 +598,7 @@ Maybe you want to use 'update --init'?")"
res=$?
if test $res -gt 0
then
- die_msg="$(eval_gettext "Failed to recurse into submodule path '\$path'")"
+ die_msg="$(modulepath=$path eval_gettext "Failed to recurse into submodule path '\$modulepath'")"
if test $res -eq 1
then
err="${err};$die_msg"
@@ -925,7 +925,7 @@ cmd_status()
cd "$path" &&
eval cmd_status "$orig_args"
) ||
- die "$(eval_gettext "Failed to recurse into submodule path '\$path'")"
+ die "$(modulepath=$path eval_gettext "Failed to recurse into submodule path '\$modulepath'")"
fi
done
}
--
1.7.9.rc0.5122.gbf05.dirty
Johannes Sixt
> - die "$(eval_gettext "'\$path' ...")"
> + die "$(modulepath=$path eval_gettext "'\$modulepath' ...")"
Note that if this works for you, then only by accident because bash is
not POSIX compliant here: eval_gettext is a shell function, and in this
case, the variable assignment at the beginning of the command should
*not* be exported according to POSIX, but bash still does.
It may be suitable as a msysgit specific solution, but is not suitable
for upstream git.
-- Hannes
karste...@dcon.de
git-sh-i18n.sh line 60ff:
eval_gettext () {
printf "%s" "$1" | (
export PATH $(git sh-i18n--envsubst --variables "$1");
git sh-i18n--envsubst "$1"
)
}
gettext.sh line 89ff:
eval_gettext () {
gettext "$1" | (export PATH `envsubst --variables "$1"`; envsubst "$1")
}
Johannes Sixt
Ah, right. Then it's OK.
-- Hannes
Johannes Schindelin
Applied and pushed.
Thanks, both,
Dscho