"Tridge touched on his role in the separation of the kernel project and BitKeeper. He couldn't talk about much, and he did not announce the release of his BitKeeper client. But he noted that there has been quite a bit of confusion and misinformation regarding what he actually did. It was not, he says, an act of wizardly reverse engineering. Getting a handle on the BitKeeper network protocol turned out to be rather easier than that.
He started by noting that a BitKeeper repository has an identifier like bk://thunk.org:5000/. So, he asked, what happens if you connect to the BitKeeper server port using telnet? A quick demonstration sufficed:
telnet thunk.org 5000
Trying 69.25.196.29...
Connected to thunk.org.
Escape character is '^]'.
```
Once connected, why not type a command at it?
help
? - print this help
abort - abort resolve
check - check repository
clone - clone the current repository
help - print this help
httpget - http get command
[...]
Tridge noted that this sort of output made the "reverse engineering" process rather easier. What, he wondered, was the help command there for? Did the BitKeeper client occasionally get confused and have to ask for guidance?
Anyway, given that output, Tridge concluded that perhaps the clone command could be utilized to obtain a clone of a repository. Sure enough, it returned a large volume of output. Even better, that output was a simple series of SCCS files. At that point, the "reverse engineering" task is essentially complete. There was not a whole lot to it."
--
It's crazy how this all snowballed and now as a result of the long chain of events 95% of the industry uses Git and we have multiple multi-billion dollar companies like GitHub/GitLab built on top of it...
Nope, we’re big believers in trunk-based development and see this as a necessary extension of it - when you’re blocked from merging into trunk (e.g. because you’re waiting for your teammates to review your code), we believe you should still be able to continue working on your new feature or refactor, but without continuing to make your PR larger and in turn more time-consuming for your teammates to review.
Stacking makes this all easy by allowing you to make smaller sets of dependent PRs so you can stay unblocked and merge into trunk more often.
That refers only to the on-prem version; we support GitHub enterprise cloud out-of-the-box, even on the free tier.
Hearing about your company size and setup, you're actually in our team plan's sweet spot. If you give it a shot, reach out and let us know what you think!
"Tridge touched on his role in the separation of the kernel project and BitKeeper. He couldn't talk about much, and he did not announce the release of his BitKeeper client. But he noted that there has been quite a bit of confusion and misinformation regarding what he actually did. It was not, he says, an act of wizardly reverse engineering. Getting a handle on the BitKeeper network protocol turned out to be rather easier than that.
He started by noting that a BitKeeper repository has an identifier like bk://thunk.org:5000/. So, he asked, what happens if you connect to the BitKeeper server port using telnet? A quick demonstration sufficed:
telnet thunk.org 5000 Trying 69.25.196.29... Connected to thunk.org. Escape character is '^]'. ```
Once connected, why not type a command at it?
help ? - print this help abort - abort resolve check - check repository clone - clone the current repository help - print this help httpget - http get command [...]
Tridge noted that this sort of output made the "reverse engineering" process rather easier. What, he wondered, was the help command there for? Did the BitKeeper client occasionally get confused and have to ask for guidance?
Anyway, given that output, Tridge concluded that perhaps the clone command could be utilized to obtain a clone of a repository. Sure enough, it returned a large volume of output. Even better, that output was a simple series of SCCS files. At that point, the "reverse engineering" task is essentially complete. There was not a whole lot to it."
--
It's crazy how this all snowballed and now as a result of the long chain of events 95% of the industry uses Git and we have multiple multi-billion dollar companies like GitHub/GitLab built on top of it...