Re: [PATCH v2 1/7] log-tree: respect diffopt's configured output file stream
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 21, 2016, 07:31 UTC
- Message-ID
- <alpine.DEB.2.20.1606210920510.22630@virtualbox>
- In-Reply-To
- <xmqqwplju74a.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Mon, 20 Jun 2016, Junio C Hamano wrote:
Show 12 quoted lines
> 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.
Show 11 quoted lines
> 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.
Show 10 quoted lines
> > 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.
Show 32 quoted lines
> > @@ -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