Re: [PATCH] Add ALL_LDFLAGS to the git target.

[Jason Riedy <ejr@EECS.Berkeley.EDU>]

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.