Bug #1253
[PATCH] git.subr grabs git stderr for ls-remote timing (due to misredirection)
| Status: | Resolved | Start date: | 06/25/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  divVerent | % Done: | 100% | |
| Category: | Repository | |||
| Target version: | - |
Description
When I run "all update", I get a failure message about "gnome-keyring:: ", which features in the stderr output of "git ls-remote", which is called in git.subr. As it turns out, git.subr misredirects stderr in (at least) one place.
The attached patch fixes that (note that the redirect happens in the other order at the other ls-remote call site).
Enjoy :-)
fix-git-subr.patch 
- swap order of redicts
(575 Bytes)
History
#1
Updated by divVerent 11 months ago
- Status changed from New to Resolved
No, your fix makes it worse ;)
It throws away the output of "time" too, which is the very thing this tries to catch. The output of "time" is on stderr, and normal git ls-remote output is on stdout, so what it does is to kill stdout and keep stderr, but move it to stdout. So, 2>&1 >/dev/null was right here...
however, now that we know git-ls-remote may use stderr too, the only solution was to put it in an explicit subshell (time sh -c ...).
#2
Updated by jonaskoelker 11 months ago
No, your fix makes it worse ;)
Doh! Oh well, at least my patch fixed my local it-doesn't-build problem.
It throws away the output of "time" too, which is the very thing this tries to catch.
If you really insist, I guess I'll reluctantly have to agree that it's mildly important to use the right success criterion. In any case, thanks for your prompt response, and for your real fix :-)