They mention that they'd ideally want a natural ordering on the commit hashes. Something to do with their zero-tolerence security policy.
What's the background there? Why do they need a natural ordering?
What's the background there? Why do they need a natural ordering?
https://git-scm.com/docs/git-describe
$ git describe 593a2a5d0639b4b4f91ff6e6ffb64e72020f8fd8
v2.34.1-83-g593a2a5d06
$ git log v2.34.1-83-g593a2a5d06
$ git show v2.34.1-83-g593a2a5d06:branch.c
It’s basically the same thing as rev-list that they do, except more readable, with tighter integration to tags and with the result usable as a commitish.
man 7 gitrevisions
[0] https://manpages.debian.org/bullseye/git-man/gitrevisions.7....
I'm guessing the tooling around this used subversion's increasing commit numbers and it was easier to add a shim to git, than to rewrite or rethink the tooling.
..unless it fixes some important security vulnerability, one hopes..
> If a patch lands that regresses performance according to our benchmarks, then the person responsible must either back the patch out of the tree or drop everything immediately and fix the regression.
I imagine that a security hotfix would lead almost immediately to the second situation (perhaps as soon as the implementor had gotten some sleep!)
Imagine bisecting builds with parallelism of two, when one of them completes, there is a 50% chance that the build on the other side of the range is now uninteresting. If you are lucky and it is interesting, you’ve only saved yourself half a step in the bisection, because when running in parallel you sliced the range in 3 rather than 2. Adding even more parallelism just makes this effect even worse.
Someone can probably work out the math better than me but you can quickly see that for 2x build power you instantly waste half the results for very marginal gain.
Just comparing the big O should also tell you this, parallelism only buys you O(N) while bisecting is O(log N).
That's complete BS. Just go search for all the perf regressions in the issue tracker.
Perhaps the regressions in the issue tracker are for things without benchmarks.
Sounds like one can push in a security bug or performance increase that is fast because it is frankly completely broken, but wouldn’t be allowed to reverse the decision at least not without finding some alternative unrelated performance increase. Features or fixes that may obviously be worth an associated dip in performance can generally not be implemented.
Under these conditions if I knew of ways to improve performance without adverse effect, as a developer I would sit on them instead of applying them because I would need a stockpile of reserves to apply in case of emergency to account for unrelated performance degrading changes that absolutely need to be made. I would also work to make sure the benchmarks were lousy and irrelevant.
Policies like this can’t be written by people with any semblance of sense. Singular mindedness on one metric and extreme policies like this can kill development and subvert goals just as lack of discipline can. Everything is a balance. Weigh performance metrics heavily by all means, but absolutism leads to the absurd.
I guess as long as Apple holds its monopoly on keeping iOS device browsers exclusively on Webkit, it will stick around though.
Sadly having had years of an inside perspective on the competence level or lack thereof of decision makers in the non-revenue generating parts of their software business, can’t say this policy surprises me.
Funnily enough I have the opposite desire - I've worked in a VC system with "natural ordering" and it once led to an incident, where I visually compared two version IDs and said "yep this release has the bug fix". Turns out this is hard to do accurately for big numbers and I was wrong. I put a big warning on our ops documentation saying "never compare version IDs visually" with a link to the postmortem!
Git doesn't have a concept of one commit being before or after another once you've branched, or any native mechanism for enforcing global state across branches.
I used SVN like this in grad school: data files included the SVN $Id$ of the script that generated them. This let you work around bugs and experimental changes. For example, you might hardcode a delay, realize it should be longer, and then eventually decide to let the experimenter adjust it on the fly. This is easy with sequential ids:
if version < 11:
delay = 50
elif 11 <= version < 29:
delay = 100
else
delay = params.delay
For example, we tracked the orientation and direction of objects moving on a screen. One update redefined 0° to be up/north/12:00 instead of the +x direction used before. The code which loaded these files checked the $Id$ value and rotated the directional data so that the entire dataset used the same definition.
In my company we have the CI server that automatically creates a new tag (sequentially) each time one pushes on the master branch.
Turns out it ultimately doesn't matter, and after nearly 15 years using git, I have not once cared about ordering of commits.