Re: [PATCH v2 26/33] diff-merges: let new options enable diff without -p

[Sergey Organov <sorganov@gmail.com>]

Elijah Newren <newren@gmail.com> writes:

> On Fri, Dec 18, 2020 at 12:32 PM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> > On Fri, Dec 18, 2020 at 6:42 AM Sergey Organov <sorganov@gmail.com> wrote:
>> >>
>> >> Elijah Newren <newren@gmail.com> writes:
>> >>
>> >> > On Wed, Dec 16, 2020 at 10:50 AM Sergey Organov
>> >> > <sorganov@gmail.com> wrote:
>>
>> [...]
>>
>> >> >> diff --git a/log-tree.c b/log-tree.c
>> >> >> index f9385b1dae6f..67060492ca0a 100644
>> >> >> --- a/log-tree.c
>> >> >> +++ b/log-tree.c
>> >> >> @@ -899,15 +899,21 @@ static int log_tree_diff(struct rev_info
>> >> >> *opt, struct commit *commit, struct log
>> >> >>         int showed_log;
>> >> >>         struct commit_list *parents;
>> >> >>         struct object_id *oid;
>> >> >> +       int is_merge;
>> >> >> + int regulars_need_diff = opt->diff ||
>> >> >> opt->diffopt.flags.exit_with_status;
>> >> >
>> >> > So rev_info.diff has changed in meaning from
>> >> > commits-need-to-show-a-diff, to non-merge-commits-need-to-show-a-diff.
>> >> > That's a somewhat subtle semantic shift.  Perhaps it's worth adding a
>> >> > comment to the declaration of rev_info.diff to highlight this?  (And
>> >> > perhaps even rename the flag?)
>> >>
>> >> No, the meaning of rev_info.diff hopefully didn't change. rev_info.diff
>> >> still enables all the commits to pass further once set. It is still
>> >> exactly the same old condition, just assigned to a variable for reuse.
>> >> My aim was to avoid touching existing logic of this function and only
>> >> add a new functionality when opt->merges_need_diff is set.
>> >>
>> >> It looks like I rather choose confusing name for the variable, and it'd
>> >> be more clear if I'd call this, say:
>> >>
>> >>   int need_diff = opt->diff || opt->diffopt.flags.exit_with_status;
>> >>
>> >> ?
>> >>
>> >> What do you think?
>> >
>> > I think need_diff would actually be confusing.  It can be false when
>> > you need diffs (e.g. --diff-merges=cc with no -p, because then you'd
>> > need diffs for merge commits and not for non-merge commits).  I'd
>> > stick with your original local variable name.
>> >
>> > Perhaps opt->diff hasn't changed meaning and I just had a wrong mental
>> > model in my head for what it meant, but even then what seems like its
>> > obvious purpose given its name is mismatched with what it actually
>> > does.  Since you are already changing struct rev_info in this series,
>> > this was more a note that a name change or at least a comment for
>> > opt->diff might be useful.  I mean, you asked a couple times on the
>> > previous series for help trying to understand it, and I could only
>> > offer some flailing guesses and Junio responded with a couple bits of
>> > history.  Clearly, it isn't very clear and this patch reminded me of
>> > that and made me wonder if we're possibly making it a little harder
>> > for others further down the road to figure out.
>>
>> I still don't see why opt->diff is needed in the first place, and
>> second, why opt->diffopt.flags.exit_with_status check is here? Why
>> whoever sets opt->diffopt.flags.exit_with_status doesn't just set
>> opt->diff as well (provided opt->diff is needed in the first place)?
>>
>> From the aforementioned discussion it looks like opt->diff is an
>> optimization (maybe a remnant from the times when diff was a separate
>> script), and that apparently there is some code instance somewhere that
>> actually relies on the fact that clearing opt->diff is enough to disable
>> diff machinery (as followed from my experiment of removing the check
>> altogether and then getting only single seemingly unrelated test
>> failing.)
>>
>> Overall, neither have I any idea how to clarify this, nor do I want to
>> bother in this patch series. It'd be nice though if somebody who really
>> does understand diff machinery in Git does the job.
>
> Doh, I was hoping you had it all figured out.

I tried. I failed. :-)

> If not, then that's a fair enough argument not to attempt to clarify.

This.

Thanks,
-- Sergey