Re: [PATCH v2 1/7] log-tree: respect diffopt's configured output file stream

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Mon, 20 Jun 2016, Junio C Hamano wrote:

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > The diff options already know how to print the output anywhere else
> > than stdout. The same is needed for log output in general, e.g.  when
> > writing patches to files in `git format-patch`. Let's allow users to
> > use log_tree_commit() *without* changing global state via freopen().
> 
> I wonder if this change is actually fixing existing bugs.  Are there
> cases where diffopt.file is set, i.e. the user expects the output to be
> sent elsewhere, but the code here unconditionally emits to the standard
> output?  I suspect that such a bug can be demonstratable in a test or
> two, if that were the case.

It is conceivable, but I did not have time to chase those cases down yet.

> I am sort-of surprised that we didn't do this already even though we
> had diffopt.file for a long time since c0c77734 (Write diff output
> to a file in struct diff_options, 2008-03-09).
> 
> Use of freopen() to always write patches through stdout may have
> been done as a lazy workaround of the issue this patch fixes, but
> what is surprising to me is that doing it the right way like this
> patch does is not that much of work.  Perhaps that was done long
> before c0c77734 was done, which would mean doing it the right way
> back then when we started using freopen() it would have been a lot
> more work and we thought taking a short-cut was warranted.

Back when I implemented the feature to write to individual files, I indeed
used freopen() out of laziness: 0377db7 (Teach fmt-patch to write
individual files., 2006-05-05). I could not have used diffopt.file at that
stage, anyway: that field still was almost two years in the future.

> >  		if (opt->children.name)
> >  			show_children(opt, commit, abbrev_commit);
> >  		show_decorations(opt, commit);
> >  		if (opt->graph && !graph_is_commit_finished(opt->graph)) {
> > -			putchar('\n');
> > +			fputc('\n', opt->diffopt.file);
> 
> Hmph.  putc() is the "to the given stream" equivalent of putchar()
> in the "send to stdout" world, not fputc().  I do not see a reason
> to force the call to go to a function avoiding a possible macro here.

TBH I did not even *know* putc(). It is amazing how you can learn new
things about the POSIX API after decades of working with it.

> Likewise for all the new fputc() calls in this series that were
> originally putchar().

Goes without saying.

> > @@ -880,8 +880,9 @@ int log_tree_commit(struct rev_info *opt, struct commit *commit)
> >  		shown = 1;
> >  	}
> >  	if (opt->track_linear && !opt->linear && opt->reverse_output_stage)
> > -		printf("\n%s\n", opt->break_bar);
> > +		fprintf(opt->diffopt.file, "\n%s\n", opt->break_bar);
> >  	opt->loginfo = NULL;
> > -	maybe_flush_or_die(stdout, "stdout");
> > +	if (opt->diffopt.file == stdout)
> > +		maybe_flush_or_die(stdout, "stdout");
> >  	return shown;
> >  }
> 
> This one looks fishy.
> 
> Back when we freopen()'ed to write patches only through stdout, we
> always called maybe_flush_or_die() to make sure that the output is
> flushed correctly after processing each commit.  This change makes
> it not to care, which I doubt was what you intended.  Instead, my
> suspicion is that you didn't want to say "stdout" when writing into
> a file.
> 
> But even when writing to on-disk files, the code before your series
> would have said "stdout" when it had trouble flushing, so I do not
> think this new "if()" condition is making things better.  If "it
> said stdout when having trouble flushing to a file" were a problem
> to be fixed, "let's not say stdout by not even attempting to flush
> and catch errors when writing to a file" would not be the right
> solution, no?
> 
> Personally, I do not think it hurts if we kept saying 'stdout' here,
> even when we flush opt->diffopt.file and found a problem.

Okay, I changed it back to be unconditional.

My original thinking was that we will fclose() the file (if it is not
stdout) anyway, which implies flushing. But the more I think about it,
the more I come to the conclusion that this is more of a side effect,
based on deep knowledge of the current code. So I now agree with you that
it would be "too clever".

Expect v3 in a moment.

Ciao,
Dscho