mbakke

For those who resonate with "why might this be useful", here are "plain git" alternatives to this tool:

> searching for a function I deleted

    git log -G someFunc

> quickly looking at a file on another branch to copy a line from it

I use `git worktree` to "mount" long-running branches much to the same effect as Julias tool. To quickly look at a file from a non-mounted branch/commit, I use:

    git show $REF:$FILENAME

> searching every branch for a function

    git log --all -G someFunc

Note that -G can be replaced with -F for a speedup if the pattern you are searching for is a fixed string.

They were also tapping the private network links of the Norwegian oil company Equinor (formerly Statoil) according to the original leaks.

It's kind of odd that neither of these oil giants have put pressure on the U.S. government as a result. They are about the only "victims" big enough to pursue the case legally.

I suspect a Supreme Court case is just about the only thing that can bring some of the remaining documents to light. Anyone with access today is almost certainly under some gag order.

I have a similar workflow, but make a bunch of commits with "git commit --fixup HEAD". (Or --squash REF).

Then on the final rebase the commits are automatically ordered with s and f as appropriate.

Although I do a fair bit of amending, too.

git rerere only "automates" conflict solving after you already solved it. As in, it remembers previous merge resolutions, even if you undo the merge/rebase.

It is particularly useful when doing difficult merges regularly. Invariably I'll find a mistake in the merge and start over (before pushing, obviously); the second "git merge" remembers the previous resolutions so I don't have to solve all the same conflicts again.

Similar for difficult rebases that may need multiple attempts.

Git remembers resolutions across branches and commits, so in the rare case where (say) a conflict was solved during a cherry-pick, rerere will automatically apply the same resolution for a merge with the same conflict.

I think the reason it's not on by default is that the UI is confusing: when rerere solves for you, git still says there is a conflict in the file and you have to "git add" them manually. There is no way of seeing the resolutions, or even the original conflicts, and no hint that rerere fixed it for you.

You just get a bunch of files with purported conflicts, yet no ==== markers. Have fun with that one if you forget that rerere was enabled.

The only "enterprise" feature of RHEL is Red Hat support.

There is nothing to standardise. If anything we need more commercially backed distributions to tear down the monoculture.

Great article. Real life horror stories of life-critical software gore, with some good news at the end.

It should be illegal to sell software that someones life depends upon without giving the user the right to inspect and modify the code.

I used to work with a guy that mounted a keyboard vertically on each side of his chair, using both at once.

A true legend.

Thank you! Setting SOURCE_DATE_EPOCH to the most recent file timestamp found in the source input is a clever hack.

How is that possible? Is nixpkgs an input to the Python derivation? Or do packagers "hard code" a value every time they modify the Python build code? Automated tooling that sets it after pull requests? Something else? :-)

It obviously depends on the hardware, but IIRC for me maybe 3-4 hours building from the 357 byte seed to the latest GCC.

The early binaries are not very optimized :-)

Typically part of a "version string":

    $ python3
    Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>>

Perhaps a relic from when software had to be manually updated?