There seems to be at least these three advantages over my approach:

  - `git duet` has neat syntax for attributing more than two people.
  - `git duet` lets me enter a mode where it keeps attributing my co-authors.
  - `git duet` keeps the authors in a separata data file, not in the script.

I eventually got tired of writing that manually, so I wrote a small

  git co-commit --thor ...

Placing it in e.g. ~/bin/git-co-commit and having ~/bin in your $PATH will enable it as a git sub-command.

I've never had a use for this before, and I don't think I'll need it much beyond this team, but this was my first git sub-command that wasn't trivially solvable by existing command parameters (that I know of).

https://gist.github.com/sshine/d5a2986a6fc377b440bc8aa096037...

First, in scientific coding, one of the big challenges is in reproducing the results of a program that uses random numbers. A classic solution is to use a deterministic pseudo-random number generator that can be seeded, such that if it's seeded with the same number on two different runs, it will always generate the same output. This could be a great replacement for that, since you could write a rand() routine that accepts a start point in the chain and traverses forward to output random values on demand.

Second, you could use this as a source of future randomness -- for example, I will award you $x if the next eight bits out of the random generator represent 0-127, and will award the $x to me if they represent 128 or greater. We can both check the value, and we don't have to trust each other.

The caveat with the last example is that we both have to trust that NIST has not been compromised ...

The anti-use would be in any sort of cryptographic implementation, since any "entropy" you'd be gaining by using this data as a source of randomness is completely counteracted by the fact that the source is known. Randomness becomes deterministic once the source of the randomness is disclosed and broadcast ...