Elijah Newren <newren@xxxxxxxxx> writes: > On Fri, Dec 18, 2020 at 12:32 PM Sergey Organov <sorganov@xxxxxxxxx> wrote: >> >> Elijah Newren <newren@xxxxxxxxx> writes: >> >> > On Fri, Dec 18, 2020 at 6:42 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: >> >> >> >> Elijah Newren <newren@xxxxxxxxx> writes: >> >> >> >> > On Wed, Dec 16, 2020 at 10:50 AM Sergey Organov >> >> > <sorganov@xxxxxxxxx> 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
