From: Jason Riedy <ejr@EECS.Berkeley.EDU>
To: git@vger.kernel.org
Subject: Re: [PATCH] Add ALL_LDFLAGS to the git target.
Date: Tue, 28 Mar 2006 11:46:28 -0800 [thread overview]
Message-ID: <15693.1143575188@lotus.CS.Berkeley.EDU> (raw)
In-Reply-To: <7vu09jks1u.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- Hmph. We do fprintf(stderr, "blah\r") to draw them. The
- standard says that "standard error stream is not fully
- buffered", but I guess it does not necessarily mean it is
- unbuffered, so we probably need to fflush(3) there. Would
- something like this help?
I suppose I should have mentioned that I tried flushing
stderr. Your more comprehensive flushing also does not
fix it, giving outputs like:
> Unpacking Total 3333 objects
> , written 33 (delta 1), reused 0 (delta 0)
The problem is that stderr from a child is not tied to any
stream of its parent. Generally, as far as I know, you
cannot make any assumptions about how pipes from separate
processes are interleaved in the output. Some standard may
say something, but I have no idea what or if anyone listens.
And this particular system is a busy SMP node, making the
problem worse.
Line-buffered streams like stdout tend to work, but not
unbuffered streams like stderr. We can't make stderr line-
buffered without breaking the status indicator...
If I add a third fd to all the pipes and dup it to stderr,
the tests work. I never read from that fd, so I never get
the status output... Progress needs to be part of the
protocol so front ends can handle it cleanly rather than
using stderr tricks.
So some possibilities:
1) Add the ability to pass options through the whole
connect system. Then pass -q in the tester.
2) Add a specific "quiet" command to the protocol for
just passing -q from git-fetch-pack. Pass -q in the
tester.
3) Add an option to pack-objects that dumps progress
output to stdout in a special packet format. Then
update everyone who talks through upload-pack to
expect another phase of informational messages after
negotiating object differences and before the pack
data.
The first two are cosmetic fixes only, and #2 is a cheap,
ugly, but easy hack.
This problem is (to me) low priority. It unfortunately
breaks a test case on AIX, but I can live with it for now.
If others here start to listen to the gospel of git, well,
I'll need to fix it. (But I once recommended Arch, and
people stopped listening after they tried it.)
Folks using moderately-loaded SMPs may experience similar
problems. But if they're fetching large packs, the problem
likely won't appear at all.
Jason
P.S. For the whole finding-a-function-name business, some of
us are using git on fixed-format Fortran. Every non-comment
line begins with whitespace... ;) And in free format, many
people don't add that first indentation within subroutines.
next prev parent reply other threads:[~2006-03-28 19:46 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-28 0:28 What's in git.git Junio C Hamano
2006-03-28 1:15 ` [PATCH] Add ALL_LDFLAGS to the git target Jason Riedy
2006-03-28 1:25 ` Junio C Hamano
2006-03-28 3:11 ` Jason Riedy
2006-03-28 6:21 ` Junio C Hamano
2006-03-28 19:46 ` Jason Riedy [this message]
2006-03-28 22:48 ` Mark Wooding
2006-03-28 23:03 ` Linus Torvalds
2006-03-28 23:20 ` Junio C Hamano
2006-03-28 23:59 ` Jason Riedy
2006-03-29 0:01 ` Junio C Hamano
2006-03-28 23:21 ` Mark Wooding
2006-03-29 0:16 ` [PATCH] Support for pickaxe matching regular expressions Petr Baudis
2006-03-29 13:09 ` Petr Baudis
2006-03-29 11:42 ` [PATCH] Add ALL_LDFLAGS to the git target Johannes Schindelin
2006-03-28 2:05 ` Gitk strangeness Linus Torvalds
2006-03-28 2:12 ` Junio C Hamano
2006-03-28 2:31 ` Paul Mackerras
2006-03-28 2:52 ` Linus Torvalds
2006-03-28 2:54 ` Junio C Hamano
2006-03-28 4:31 ` Paul Mackerras
2006-03-28 5:38 ` Junio C Hamano
2006-03-28 6:18 ` Paul Mackerras
2006-03-28 7:52 ` Junio C Hamano
2006-03-28 22:51 ` Paul Mackerras
2006-03-29 0:50 ` Junio C Hamano
2006-03-29 6:41 ` Junio C Hamano
2006-03-30 20:57 ` Alex Riesen
2006-03-30 22:33 ` Paul Mackerras
2006-03-30 23:46 ` Paul Mackerras
2006-03-31 1:50 ` Junio C Hamano
2006-03-31 6:27 ` Alex Riesen
2006-03-28 2:57 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15693.1143575188@lotus.CS.Berkeley.EDU \
--to=ejr@eecs.berkeley.edu \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).