All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Stefan Beller <sbeller@google.com>
Cc: git <git@vger.kernel.org>, David Turner <novalis@novalis.org>
Subject: Re: [PATCH 2/6] diff: clear emitted_symbols flag after use
Date: Thu, 24 Jan 2019 14:11:24 -0500	[thread overview]
Message-ID: <20190124191124.GB29828@sigill.intra.peff.net> (raw)
In-Reply-To: <CAGZ79kbHLvN252v-gNbcpsyGg8pZ9GPBtyZquX50HwhtYep5oA@mail.gmail.com>

On Thu, Jan 24, 2019 at 10:55:10AM -0800, Stefan Beller wrote:

> >      But where does that output go? Normally it goes directly to stdout,
> >      but because o->emitted_symbols is set, we queue it. As a result, we
> >      don't actually print the diffstat for the merge commit (yet),
> 
> Thanks for your analysis. As always a pleasant read.
> I understand and agree with what is written up to here remembering
> the code vaguely.
> 
> > which
> >      is wrong.
> 
> I disagree with this sentiment. If we remember to flush the queued output
> this is merely an inefficiency due to implementation details, but not wrong.
> 
> We could argue that it is wrong to have o->emitted_symbols set, as
> we know we don't need it for producing a diffstat only.

It's wrong in the sense that we finish printing that merge commit
without having shown its diff. If it were the final commit, we would not
ever print it at all!

So if you are arguing that it would be OK to queue it as long as we
flushed it before deciding we were done with the diff, then I agree. But
doing that correctly would actually be non-trivial, because the
combined-diff code does not use the emitted_symbols queue for its diff
(so the stat and the patch would appear out of order).

I also wondered why diffstats go to o->emitted_symbols at all. We do not
do any analysis of them with --color-moved, I don't think. But I can
also see that having emitted_symbols hold everything makes sense from a
maintainability standpoint; future features may want to see more of what
we're emitting.

> >   3. Next we compute the diff for C. We're actually showing a patch
> >      again, so we end up in diff_flush_patch_all_file_pairs(), but this
> >      time we have the queued stat from step 2 waiting in our struct.
> 
> Right, that is how the queueing can produce errors. I wonder if the
> test that is included in this patch would work on top of
> e6e045f803 ("diff.c: buffer all output if asked to", 2017-06-29)
> as that commit specifically wanted to make sure these errors
> would be caught.

I suspect that would not work with "--cc", because combine-diff outputs
directly stdout. That's something that we might want to improve in the
long run (since obviously it cannot use --color-moved at this point).

> > To fix it, we can simply restore o->emitted_symbols to NULL after
> > flushing it, so that it does not affect anything outside of
> > diff_flush_patch_all_file_pairs(). This intuitively makes sense, since
> > nobody outside of that function is going to bother flushing it, so we
> > would not want them to write to it either.
> 
> This would also cause the inefficiency I mentioned after (2) to disappear,
> as the merge commits diffstat would be just printed to stdout?

Yes, it avoids the overhead of even storing them in the emitted struct
at all.

> Reviewed-by: Stefan Beller <sbeller@google.com>

Thanks!

I did quite a bit of head-scratching figuring out this bug, but at the
end of it I now understand the flow of the color-moved code quite a bit
better. :)

-Peff

  reply	other threads:[~2019-01-24 19:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 12:26 [PATCH 0/6] some diff --cc --stat fixes Jeff King
2019-01-24 12:27 ` [PATCH 1/6] t4006: resurrect commented-out tests Jeff King
2019-01-24 18:18   ` Stefan Beller
2019-01-24 12:32 ` [PATCH 2/6] diff: clear emitted_symbols flag after use Jeff King
2019-01-24 18:55   ` Stefan Beller
2019-01-24 19:11     ` Jeff King [this message]
2019-01-24 20:18   ` Junio C Hamano
2019-01-24 20:36     ` Stefan Beller
2019-01-24 21:17       ` Jeff King
2019-01-24 21:15     ` Jeff King
2019-01-24 12:33 ` [PATCH 3/6] combine-diff: factor out stat-format mask Jeff King
2019-01-24 12:34 ` [PATCH 4/6] combine-diff: treat --shortstat like --stat Jeff King
2019-01-24 18:58   ` David Turner
2019-01-24 19:02   ` Stefan Beller
2019-01-24 12:35 ` [PATCH 5/6] combine-diff: treat --summary " Jeff King
2019-01-24 19:14   ` Stefan Beller
2019-01-24 19:23     ` Jeff King
2019-01-24 12:36 ` [PATCH 6/6] combine-diff: treat --dirstat " Jeff King
2019-01-24 19:21 ` [PATCH 0/6] some diff --cc --stat fixes Stefan Beller

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190124191124.GB29828@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=novalis@novalis.org \
    --cc=sbeller@google.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.