Re:Git 2.19.0 released
by tialaramex on Wednesday September 12, 2018 @01:15PM
(#17970909)
"git bisect" is my overall favourite feature, I think it's illustrative of the same widely applicable phenomenon as git itself. Lots of people would know in principle that this idea - binary search for a change introduced at some unknown previous point - is a good way to approach the problem, many of them could implement such a thing, but for whatever particular problem it may never seem like it's quite worth the effort to do so. But, by expending this effort just once (as "git bisect") our culture gets the reap the benefit essentially forever.
But if you use git around me the thing I'll keep talking about is force with lease (as seen in e.g. "git push --force-with-lease"). I believe this is a specific implementation of an idea with much broader possibilities that we should see in a LOT more places.
The central idea of force-with-lease is that when I'm telling a machine that I understand all the circumstances and nevertheless I wish to proceed anyway, I should need to tell the machine what these circumstances are that I'm claiming to understand. For example I know the current state of the tree is rel-4.2.6-20180911 and I'm confident that we want to smash that, and put rel-4.2.6-20180912 there, even though that rewrites history. Then the machine can check automatically that those _are_ the circumstances and refuse to override if not.
In git the reason to have this feature is that it prevents the situation where I think rel-4.2.6-20180911 is in the branch, I'm sure I want rel-4.2.6-20180912 there, so I force that, but unfortunately while I was deciding to do that somebody else landed rel-4.2.7-20180912 and so I've ruined everything by forcefully reverting their change.
The broader idea is very widely applicable. In Puppet for example, somebody can tell the system to stop updating node-04 because "Barry found a problem with XYZ on this node, check with Barry before re-enabling". And if you try to update node-04 it will recite that blurb and refuse. But, you can force enable node-04 without reading the blurb, and worse, if meanwhile another engineer changes it to "Figured out XYZ. Definitely don't re-enable Puppet without talking to me, Sarah" you won't even know that happened, your override will take effect anyway even though you'd no chance to know you should call Sarah.
Even in non-IT systems I think this approach has great merits. Consider a railway signal system. Most of the system isn't the "signals" (which are mostly boringly simple and reliable colored lamps) but the sensors verifying that the state of the system is consistent and safe. Humans are often authorised to overrule this system in small ways when things go wrong. A sensor says it isn't sure if the motorised points at a junction are closed, so the system refuses to move signals from "Danger" for that junction. The human signaller is authorised to tell human train drivers to ignore this Danger signal and proceed, albeit it "at caution, obeying all other signals". But wouldn't it be better if the system required the humans to acknowledge specifically that they've understood the problem is that the sensor says these points aren't locked? Now the driver is thinking about the points, which might not be locked, rather than just vaguely knowing something, somewhere, is busted. Guess who is going to take a proper look at those points before driving over them now! And when the next train arrives, and the signaller tries to let it through, if in fact NOW the problem is that the points are fine but the axle counter says the previous train never left, the signaller would need to diagnose and accept this situation, not just wave through another train assuming it's the same fault because it has the same symptom (signal at danger).
But if you use git around me the thing I'll keep talking about is force with lease (as seen in e.g. "git push --force-with-lease"). I believe this is a specific implementation of an idea with much broader possibilities that we should see in a LOT more places.
The central idea of force-with-lease is that when I'm telling a machine that I understand all the circumstances and nevertheless I wish to proceed anyway, I should need to tell the machine what these circumstances are that I'm claiming to understand. For example I know the current state of the tree is rel-4.2.6-20180911 and I'm confident that we want to smash that, and put rel-4.2.6-20180912 there, even though that rewrites history. Then the machine can check automatically that those _are_ the circumstances and refuse to override if not.
In git the reason to have this feature is that it prevents the situation where I think rel-4.2.6-20180911 is in the branch, I'm sure I want rel-4.2.6-20180912 there, so I force that, but unfortunately while I was deciding to do that somebody else landed rel-4.2.7-20180912 and so I've ruined everything by forcefully reverting their change.
The broader idea is very widely applicable. In Puppet for example, somebody can tell the system to stop updating node-04 because "Barry found a problem with XYZ on this node, check with Barry before re-enabling". And if you try to update node-04 it will recite that blurb and refuse. But, you can force enable node-04 without reading the blurb, and worse, if meanwhile another engineer changes it to "Figured out XYZ. Definitely don't re-enable Puppet without talking to me, Sarah" you won't even know that happened, your override will take effect anyway even though you'd no chance to know you should call Sarah.
Even in non-IT systems I think this approach has great merits. Consider a railway signal system. Most of the system isn't the "signals" (which are mostly boringly simple and reliable colored lamps) but the sensors verifying that the state of the system is consistent and safe. Humans are often authorised to overrule this system in small ways when things go wrong. A sensor says it isn't sure if the motorised points at a junction are closed, so the system refuses to move signals from "Danger" for that junction. The human signaller is authorised to tell human train drivers to ignore this Danger signal and proceed, albeit it "at caution, obeying all other signals". But wouldn't it be better if the system required the humans to acknowledge specifically that they've understood the problem is that the sensor says these points aren't locked? Now the driver is thinking about the points, which might not be locked, rather than just vaguely knowing something, somewhere, is busted. Guess who is going to take a proper look at those points before driving over them now! And when the next train arrives, and the signaller tries to let it through, if in fact NOW the problem is that the points are fine but the axle counter says the previous train never left, the signaller would need to diagnose and accept this situation, not just wave through another train assuming it's the same fault because it has the same symptom (signal at danger).