On Sun, 16 May 2021, Felipe Contreras wrote: > Bagas Sanjaya wrote: > > On 16/05/21 14.32, Anders Höckersten via GitGitGadget wrote: > > > @@ -139,8 +140,11 @@ at the end. > > > > > > The number of additional commits is the number > > > of commits which would be displayed by "git log v1.0.4..parent". > > > -The hash suffix is "-g" + unambiguous abbreviation for the tip commit > > > -of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). > > > +The hash suffix is "-g" + an unambigous abbreviation for the tip commit > > > +of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). The > > > +length of the abbreviation scales as the repository grows, using the > > > +approximate number of objects in the repository and a bit of math > > > +around the birthday paradox, and defaults to a minimum of 7. > > > > What is the birthday paradox then? > > It's a probability fact that goes against common sense. In a romm > with 23 people you are 50% likely to find two people with the same > birthday. > > https://en.wikipedia.org/wiki/Birthday_problem i've had to explain the logic behind this to people who really have a tough time understanding this, and it's a concept that applies in a lot of places (surprisingly). what trips people up is thinking they need to calculate the probability that two or more people have the same birthday. no. what you want to do is calculate the ongoing probability that each person's birthday is *different* from all the earlier ones. as in: * prob that 2nd person has a different bday is 364/365 * prob that 3rd person has a different bday is 363/365 * prob that 4th person has a different bday is 362/365 and so on, and as you multiply those together, it's right at 23 people that the chance that that person has a different bday from all earlier ones drops below 50%. what's neat is that this way of looking at things applies in a lot of places. rday
