The central repository is the only point that knows (with 100% certainty) which ref the branch was set to before the force push.
Each distributed node only knows the ref the branch was pointing at the last time they fetched, so their certainty on what the branch looked like before the force push is much lower.
> The central repository is the only point that knows (with 100% certainty) which ref the branch was set to before the force push.
git reports it to you when you do the force push:
% git push github master --force
…
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/foo/repo.git
+ 4d44b63...ad5b147 master -> master (forced update)
^ ^
previous what you've forced it to
Of course, if you lose the output, then yes, the reflog is the only thing that has it. But force pushing is so rare, and something that (should) is done with care, I'm puzzled as to how someone "accidentally" >150 repos.
If losing this output is such a problem and force pushing is so rare, then Github could email this output with the two hashes to every developer on every force push.
I was assuming after the fact as that information is not saved anywhere client side.
Also I am not sure what he did to push to 150 remotes, and in that case this output would be much more tedious to piece together (and that is assuming he was able to capture all of it).
However I disagree that force pushing is rare, I find it is a (sharp) tool I use most days (more often on private repos or branches).
I do like the idea of github providing some kind of web interface to view the reflog and reset branches to various points within it.
Git provides all the pieces, we just need to put them together in the right way.
The issue is that a client may not have fetched for a while before performing the force push, so it may not have all the required refs for performing the rollback.
The server of course still has all the refs, so it shouldn't be too hard to add a command (run client side) to invoke the required server-side rollback.
In the case of git 'rewriting history' is not really the problem, and it leaves the old history intact (you cannot change git history, but you can create an alternative history).
The old history will possibly be garbage collected eventually, but for quite a while that history is still accessible.
I think the only missing piece is a simple (and obvious) client side 'undo/rollback that force push'.
The issue is that the git client may not have the history pre-force, so it may have insufficient information to do the rollback (at least in the current model), however the server still has all the refs (and they are listed in the reflog).
Yes, the ability to rollback history more easily than paging through `git reflog` would be great. (in particular, if you rebase often you end up with a lot of cruft).
Locally in git you have the HEAD@{n} notation to step back n steps through the reflog, so after a bad rebase a `git reset --hard HEAD@{1}` should be all you need.
It is possible that the current tech used in robotics will somehow form the basis for the work over the next 1000 years or so, either directly or via some tangential discovery by researchers working with current tech.
Without the benefit of hindsight it is impossible to tell with certainty what techs are worthwhile exploring and what should simply be discarded, the idea of discarding is of course based on the false assumption that techs that are later unused never had a use (e.g. we may solve a software problem with current tech that will form the basis for future robotics software).
Scissor switches can be quite comfortable, and the macbook air has quite nice switches (IMO I like the thinkpad x1 carbon's a little better, but it is close), and the location of the trackpad being under the keys is much more comfortable than having a physical mouse to the left or right.
For my desktop I have a kinesis advantage, but I often find using my thinkpad for long periods of time to be very comfortable, I just wish I could find a decent trackpad for my desktop(s).
FWIW I type on a mechanical keyboard daily (cherry mx browns) but I am not a fan of the model m keys (buckling springs or rubber dome IIRC), they are very different in feeling.
My Thinkpad x1 carbon keyboard comes next, scissor switches can be quite nice.
Although this is subjective, the kinesis advantage keyboard has really helped me better deal with my RSI; it has clusters of keys under each thumb and is fully programmable so I am able to move problem keys around (for me pinky keys are quite uncomfortable).
For me shift, space, backspace, tab, win, ctrl, alt, esc and enter are all thumb operations.
However I wouldn't go as far as saying it has solved my RSI, but it is definitely part of the solution that allows me to program 40+ hours a week (more like 50-60, 40 hour week professional + hobby programming).
FWIW the other parts include regular exercise, alternating mouse hands and using a trackball on my 'off hand', and a keyboard-heavy system (vim, dwm, etc.).
This is extremely cool, I am becoming more interesting in the idea of trying to write a small toy language and articles like this excite and inform, great work.
Each distributed node only knows the ref the branch was pointing at the last time they fetched, so their certainty on what the branch looked like before the force push is much lower.