Re: [PATCH v3 09/20] range-diff: adjust the output of the commit pairs

Hi Stefan,

On Fri, 20 Jul 2018, Stefan Beller wrote:

quoted

    1. To roll again.

        A player who rolls two sixes can reroll the dice for an additional
        turn.

This is where I had my AHA moment!
(Consider my software development process as chaotic as a dice roll
So rerolling is really just rolling the dice again to "get my patch
accepted" ;-)

Wouldn't that be nice? But you only get to reroll if you had two sixes.
Tough luck for you, Stefan.

quoted

    2. (programming) To convert (an unrolled instruction sequence) back into
       a loop. quotations ▼

We do not have unrolled loops?

When resending patch series? *rolls eyes*

This was good back in the day where the cost of each instruction weighted
heavy on the CPU, such that the JMPs that are needed (and the loop
variable check that might have had a bad branch prediction) for the loop were
slowing down the execution.

Nowadays (when I was studying 5 years ago) the branch prediction and
individual instruction execution are really good, but the bottleneck
that I measured (when I had a lot of time at my disposal and attending a
class/project on micro architectures), was the CPU instruction cache
size, i.e. loop unrolling made the code *slower* than keeping tight
loops loaded in memory.
https://stackoverflow.com/questions/24196076/is-gcc-loop-unrolling-flag-really-effective

quoted

Noun

reroll (plural rerolls)

    (dice games) A situation in the rules of certain dice games where a
    player is given the option to reroll an undesirable roll of the dice.


You will notice how this does not list *any* hint at referring to
something that Junio calls "reroll".

We have undesirable patches that were 'rolled' onto the mailing list,
so they have to be rerolled?

quoted

Footnote *1*: https://en.wiktionary.org/wiki/commit#Noun does not even
bother to acknowledge our use of referring to a snapshot of a source code
base as a "commit".

When Git was a content addressable file system, a commit was precisely
"a database transaction, [...] making it a permanent change."

Side note:
I was just giving a talk to my colleagues about diff aglorithms
(and eventually describing a bug in the histogram diff algorithm)
and we got really riled up with "Longest Common Subsequence",
as the mathematical definition is different than what the code
or I (after studying the code) had in mind.

Naming things is hard, and sometimes the collective wisdom got
it wrong, but changing it would be very costly in the short/medium
term.

My point is not that naming is hard. But picking names that are
*different* from what is established nomenclature is... unwise.

In this case, it makes an already unnecessarily awkward code contribution
process even more unnecessarily uninviting.

Another note about "rolling things": At $DAYJOB I review changes
that are committed to the another revision control system w.r.t. its
compliance of open source licenses (hence I am exposed to a lot
of different projects), and some of those changes are titled
"Roll up to version $X" which I found strange, but knew
what was meant.

To "roll up" is, as far as this non-native speaker can tell, an
established way to express this action.

In short: nothing you wrote can adequately defend why the Git project
chooses to confuse new contributors seemingly on purpose.

Ciao,
Dscho