Hi Stefan, On Fri, 20 Jul 2018, Stefan Beller wrote: > > 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. > > 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 > > > 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? > > > 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
