On Thu, Jul 11, 2013 at 8:55 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> Eric Sunshine wrote:
>> On Thu, Jul 11, 2013 at 3:07 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> Eric Sunshine <sunsh...@sunshineco.com> writes:
>>>> With the introduction of check-mailmap, it is now possible to check
>>>> .mailmap functionality directly rather than indirectly as a side-effect
>>>> of other commands (such as git-shortlog), therefore, do so.
>>> Does this patch mean that we will now ignore future breakages in
>>> shortlog and blame if their mailmap integration becomes buggy?
>>> I am not convinced it is a good idea if that is what is going on.
>> I meant to mention in the cover letter that this patch was open for
>> debate, however, it does not eliminate all testing of these other
>> The tests in which git-check-mailmap is substituted for git-shortlog
>> all worked against a simplistic two-commit repository. Those tests
>> were checking the low-level mailmap functionality under various
>> conditions and configurations; they were not especially checking any
>> particular behavior of git-shortlog.
>> There still remain a final eight tests which cover git-shortlog,
>> git-log, and git-blame. These tests do check mailmap-related behavior
>> of those commands, and they do so using a more involved seven-commit
>> repository with "complex" mappings, so we have not necessarily lost
>> any checks of mailmap integration for those commands.
>> Would this patch become more palatable if I stated the above in the
>> commit message?
> My current thinking is "no" --- the patch has as a justification "Now
> we can test these aspects of .mailmap handling directly with a
> low-level tool instead of using the tool most people will use, so do
> so", which sounds an awful lot like "Reduce test coverage of commonly
> used tools, because we can".
> But I imagine the actual motivation was something other than "because
> we can".
The motivation is as stated in the subject: Direct rather than
indirect testing of mailmap functionality. The tests in question are
properly crafted to check only low-level mailmap (not git-shortlog)
functionality under various conditions and configurations, yet the
mental load on the reader is high because he has to keep in mind the
authors and commits in the repository underlying git-shortlog's
output. When testing via git-check-mailmap, mental load is low: there
is a direct correlation between the "Name <email@address>" which goes
in and that which comes out. What is being tested is the same, but
it's easier to reason about and understand the the tests when done
When converting the tests, I also discovered an additional, perhaps
more important motivation. Most of the tests check only that name
remapping functions correctly, however, a couple also attempt to check
address remapping (b...@company.xx => b...@company.xy). Even though
the tests succeed, they don't actually prove that address remapping
was correct (or occurred at all) since git-shortlog does not display
the email address. git-check-mailmap always displays the email
address, thus the check actually tests the intended email address
> For example, maybe the idea is that after this patch, it
> should be easier to make cosmetic improvements to the shortlog, log,
> and blame output and only have to change those final 8 tests that are
> adequately covering the output? If you have such plans and this patch
> makes them easier, it could sound like a good patch as a stepping
> stone toward that.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html