* problems GIT_TRACE
@ 2006-07-10 11:05 Matthias Lederhofer
2006-07-10 12:22 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Lederhofer @ 2006-07-10 11:05 UTC (permalink / raw)
To: git
I just discovered a problem with GIT_TRACE. Some scripts redirect
stderr to stdout and the trace messages go with it. For example from
git-repack:
> name=$(git-rev-list --objects --all $rev_list 2>&1 |
> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
> exit 1
Then for example git-pack-objects complains:
> fatal: expected sha1, got garbage:
> trace: built-in: git 'rev-list' '--objects' '--all'
git-grep '2>&' shows a few other places that do this too, I'll take a
closer look at this later. Is there any reason to redirect stderr to
stdout? I think this will always fail with such a strange error
message when something is written to stderr.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: problems GIT_TRACE
2006-07-10 11:05 problems GIT_TRACE Matthias Lederhofer
@ 2006-07-10 12:22 ` Junio C Hamano
2006-07-10 13:12 ` [PATCH] fix git-repack for use with GIT_TRACE Matthias Lederhofer
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2006-07-10 12:22 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
Matthias Lederhofer <matled@gmx.net> writes:
> I just discovered a problem with GIT_TRACE. Some scripts redirect
> stderr to stdout and the trace messages go with it. For example from
> git-repack:
>> name=$(git-rev-list --objects --all $rev_list 2>&1 |
>> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
>> exit 1
> Then for example git-pack-objects complains:
>> fatal: expected sha1, got garbage:
>> trace: built-in: git 'rev-list' '--objects' '--all'
> git-grep '2>&' shows a few other places that do this too, I'll take a
> closer look at this later. Is there any reason to redirect stderr to
> stdout? I think this will always fail with such a strange error
> message when something is written to stderr.
This particular one is trying to catch an error condition from
rev-list. Shell reports the exit status from the last command
in the pipeline, and when rev-list notices a corrupt repository,
it wants to tell pack-objects to stop producing incorrect pack,
but there is no way other than sending a garbage string (as an
error message) to cause pack-object to notice there is garbage
coming in.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] fix git-repack for use with GIT_TRACE
2006-07-10 12:22 ` Junio C Hamano
@ 2006-07-10 13:12 ` Matthias Lederhofer
2006-07-11 0:11 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Lederhofer @ 2006-07-10 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
---
Junio C Hamano <junkio@cox.net> wrote:
> This particular one is trying to catch an error condition from
> rev-list. Shell reports the exit status from the last command
> in the pipeline, and when rev-list notices a corrupt repository,
> it wants to tell pack-objects to stop producing incorrect pack,
> but there is no way other than sending a garbage string (as an
> error message) to cause pack-object to notice there is garbage
> coming in.
Ok, this patch should fix this. Instead of "echo abort" another more
meaningful message could be used. I checked the other scripts which
redirect stderr and they should be fine. In the tests I found
t/t1200-tutorial.sh:38
t/t1300-repo-config.sh:276
t/t5500-fetch-pack.sh:66
redirecting stderr, which probably fail which GIT_TRACE.
git-cvsserver.perl:2138 has 2>&1 but uses an regexp to match for the
content, so the trace message should not make a problem. Can someone
using git-cvsserver confirm this? Perhaps this should be changed to
2>/dev/null anyway.
---
git-repack.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 640ad8d..4dd7dad 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -43,7 +43,7 @@ case ",$all_into_one," in
;;
esac
pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
-name=$(git-rev-list --objects --all $rev_list 2>&1 |
+name=$( (git-rev-list --objects --all $rev_list || echo abort) |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
exit 1
if [ -z "$name" ]; then
--
1.4.1.gf157-dirty
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] fix git-repack for use with GIT_TRACE
2006-07-10 13:12 ` [PATCH] fix git-repack for use with GIT_TRACE Matthias Lederhofer
@ 2006-07-11 0:11 ` Junio C Hamano
0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2006-07-11 0:11 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
Matthias Lederhofer <matled@gmx.net> writes:
> Ok, this patch should fix this. Instead of "echo abort" another more
> meaningful message could be used.
"git-rev-list died with exit code $?" perhaps.
> I checked the other scripts which
> redirect stderr and they should be fine. In the tests I found
> t/t1200-tutorial.sh:38
> t/t1300-repo-config.sh:276
> t/t5500-fetch-pack.sh:66
> redirecting stderr, which probably fail which GIT_TRACE.
Probably t/test-lib.sh should unset GIT_TRACE then like it does
for other environment variables.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-07-11 0:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-10 11:05 problems GIT_TRACE Matthias Lederhofer
2006-07-10 12:22 ` Junio C Hamano
2006-07-10 13:12 ` [PATCH] fix git-repack for use with GIT_TRACE Matthias Lederhofer
2006-07-11 0:11 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox