void
    dingdong()
    {
     /* RRRIIINNNGGG RRRIIINNNGGG */
    }
    
    setalarm(n)
     int n;
    {
     signal(SIGALRM, dingdong);
     alarm(n);
    }

For example: I was recently unable to unearth from it exactly when the BSD ps command changed to using getopt() and minus signs for arguments. The entire history of the FreeBSD repository back to the original 4.4BSD commits has ps using getopt(), and minus signs have been the only option syntax documented in the ps(1) manual page for all of that time, too.

* https://svnweb.freebsd.org/base/head/bin/ps/ps.c?revision=15...

* https://svnweb.freebsd.org/base/head/bin/ps/ps.1?revision=15...

This repository, alas, does not yield very much further information.

* https://groups.google.com/d/msg/mod.sources/H-shkbdVIbs/VJUI...

Note how the year selector on the right of "Contribution activity" is broken - seems it can't fit 1970-2019. Same happens with Ken Thompson's profile.

For this alone, all the work paid off.

On a more serious side, I wonder what we can learn from this data. Its not a question for the field of computational social science, but social science of computation!

https://github.com/franzinc/clim2

First commit 1991.

I've run into this with source code archeology projects. Git is ill-suited to integrating newly discovered pre-history/missing intermediary history steps. Any new historical change, out of necessity, alters all subsequent commit hashes. This means collaboration and permalinks can't happen like with "normal" Git repos.

Does anyone know of any tooling or an alternate vcs which has the ability to integrate new pre-history or alternate history (e.g. original branch commits alongside a squash and merge commit) without requiring completely breaking/re-writing the entire tree?

This comes at the cost of having intentionally multiple histories and is not well-suited for complicate cases, but for the common case of "we want to stitch this old CVS-history to this commit", it does a good job.

Usability-wise, replace refs are not cloned automatically and some web-based tools lack support for it.

Immediately after `git init`, do `git commit --allow-empty -m"initial empty commit"`. Now you have an empty commit, and any other repo which has this empty commit has some history in common with your repo.

The SHA-1 hash is well-known and there are plenty of articles you can find about it, if you search for 4b825dc642cb6eb9a060e54bf8d69288fbee4904

Here's one for example:

https://stackoverflow.com/questions/9765453/is-gits-semi-sec...

I'm not sure this helps for projects which have a shared development history, but not a shared commit history. But within an organization, where you have projects which may split and/or merge, it can help to bridge some gaps.

Is the really only reason why people do this, so that you can rewrite your initial working commit in a rebase? I think that might be it. (You can't easily rewrite the initial commit with a rebase.)

I guess the part from before SCCS was still meticulously reconstructed?

Edit: this doesn't actually answer your question of where unix used to live, rather than linux though....

No - BitKeeper revoked the free license because some guy (unrelated to Linux) wrote a client that reverse engineered more features than BitKeeper liked.

And Linux actually used BitKeeper only between 2002 and 2005; prior to that time, it did not use a source control system at all.

(way I envision it is that their committees being their own branches, along with the chambers of congress

even though its not part of the git protocol, the GUI element of the Pull Request feature could have continuous integration that showed when a threshold of votes were passed to get something into to the next branch like out of committee and onto the floor

then after whichever path was taken to get something codified into law, it is merged into the master branch where the agencies have their own process to update the code of federal regulations)

I'm wondering if Fossil would be more suited to this than Git.