Junio C Hamano <gitster@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Is your naming convention that "rev_diff_" is the common prefix? >> What's the significance of "_diff" part? After all, these are about >> tweaking the setting in the rev_info structure, so how about >> >> revinfo_show_merges_in_dense_combined_by_default(rev); >> revinfo_show_merges_by_default_with_first_parent(rev); >> >> perhaps, using just "revinfo_" as the common prefix? > > Actually, I'd like to take these suggestions back. I do not think > these names that describe "what the function does" are good names at > all. If we can name them after what they are for, we'd be much > better off. > > Given that one is part of the tweak for "show" and the other part of > "log", I presume that one is to set-up default for showing a merge > in the context of the "show" command, and the other is the same for > the "log" (actually "log -p") command. So perhaps > > diff_merges_set_default_for_show(revs); > diff_merges_set_default_for_log(revs); > > are good names that tells us where they should be used and what for. Sorry, here I disagree, see below. > The former is to set up the default parameters to handle a merge > commit in the context of the "show" command, and the latter is the > same for the "log" command. Naming them that way, we can then tweak > what should happen for "show" by default without touching the caller > if we wanted to (perhaps, "when doing first-parent traversal, really > pretend that all the commits we see are single-parent, so show the > change relative to its first parent by default without even > requiring -m" might be something the latter can learn later). I have multiple objections to this: 1. diff-merges, as a module or unit, is designed to provide needed services to callers, not to dictate where exactly these services are to be used. 2. diff-merges, as a module, should not care nor know if "git log" or "git show" (or whatever top-level command), exists at all, so the suggested names are not a good idea to have in the module. 3. The decision how exactly merge commits are to be shown for given user command should better be expressed in that command, not hidden in the implementation of diff-merges module. 4. Giving functions names by their place of call won't allow to sensibly reuse them in other places, if needed, without renaming. Overall, I believe the functions in the diff-merges unit must be called after what they are doing to the format of the diff output for merges, not after the places they are (currently) called at. The functions you suggest, on the other hand, are fine and may have their place, but they are at higher level of abstraction and should not be part of the low-level diff-merges module. Thanks, -- Sergey Organov
