Bilal El Khatabi <elkhatabibilal@gmail.com> writes:

These two sentences repeat almost the same thing in different phrasing, which starts to become a bit boring.

The gold standard way to write a proposed commit log message for this project is to:

 - Give an observation on how the current system works in the
   present tense (so no need to say "Currently X is Y", or
   "Previously X was Y" to describe the state before your change;
   just "X is Y" is enough), and discuss what you perceive as a
   problem in it.

 - Propose a solution (optional---often, problem description
   trivially leads to an obvious solution in reader's minds).

 - Give commands to somebody editing the codebase to "make it so",
   instead of saying "This commit does X".

in this order. The above jumps directly to the execution, bypassing the observation and solution. Fully followed, it would become something like:

    When a test in t5315 tries to see if a loose object file is
    created at the expected path in the filesystem, "test -f" is
    used.  If a developer breaks "git" in such a way that the file
    is no longer created at this expected place, however, "test -f"
    will silently fail and exits with non-zero, causing the test
    fail, but it is not obvious which step in the &&- chained
    commands failed.

    Use test_path_is_file helper, which loudly reports the failure
    when the expectation is not met.  When running the test with the
    "-v" option, i.e., "sh t5315-*.sh -v", the failure would become
    more prominent, helping the developer.

Will queue.