At long last, git is supported at rsync.net.
We wrestled with the decision to add it for some time, as we place a very, very high value on the simplicity of our systems. We have no intention of turning rsync.net into a development platform, running a single additional network service, or opening a single additional TCP port.

At the same time, there are a number of very straightforward synchronization and archival functions inherent to subversion and git that lend themselves very well to our offsite filesystem.

Re: Yes and no
OK, here's the situation.

you fork an upstream repo, your fork is private

you commit something there that should not see daylight (keys to the Lamborghini or whatever)

you delete that commit to hide your sins

and now that commit is apparently still easily accessible from upstream. //

Re: Yes and no

Also - as far as I can see it's not actually possible to create private native GitHub forks of public repos in GitHub

The example they cite is when you have a private repo that will eventually become public, fork it to make permanently-private fork and then later make the original repo public. Anything commited to the still-private repo up until the point the first repo is made public, can be accessed from the now-public repo. (As long as you know the commit hashes, that is - but unfortunately they're easily discoverable.) //

The issue is that people are mentally modelling forks as "that's my copy of the repo, completely separate from the original" whereas in reality the fork is just a different interface to the same pool of blobs. Furthermore, while you wouldn't be able to access commits from another fork in the same pool of blobs unless you know the commit hash, github makes those commit hashes discoverable. //

Re: Yes and no
For the people downvoting me - you are aware how quickly AWS credentials accidentally exposed on GitHub are found and abused by attackers? Honeypot tests suggest 1 minute.

https://www.comparitech.com/blog/information-security/github-honeypot/

Note that at no point in the "what to do if you've exposed credentials" section does it say "delete the public repo in the hope that this will alter the past". Magical thinking.

Having played around with this on GitHub, I will say that the message on trying to delete a repo isn't explicit enough about the unexpected (if documented) behaviour. It really ought to have a disclaimer that says "If you're trying to delete commits you wish you hadn't pushed everywhere, this won't achieve it", and a link to a page describing what will actually help. //

What happens in Repo Stays In Repo
"It's reasonable to expect that deleting a commit tree that nobody else has yet accessed will prevent it from being accessed in future."

No it isn't. It's supposed to be a history. In a code repo, the ability to permanently delete past changeset data should be considered a bug or design flaw. The inability to lose history is the whole point.

Source code has no right to be forgotten, when it's in an SCM, because the point of the SCM is to remember.

git-annex allows managing files with git, without checking the file contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, time, or disk space.

git-annex is designed for git users who love the command line. For everyone else, the git-annex assistant turns git-annex into an easy to use folder synchroniser.

Windows is live on Git

Over the past 3 months, we have largely completed the rollout of Git/GVFS to the Windows team at Microsoft.

As a refresher, the Windows code base is approximately 3.5M files and, when checked in to a Git repo, results in a repo of about 300GB. Further, the Windows team is about 4,000 engineers and the engineering system produces 1,760 daily “lab builds” across 440 branches in addition to thousands of pull request validation builds. All 3 of the dimensions (file count, repo size and activity), independently, provide daunting scaling challenges and taken together they make it unbelievably challenging to create a great experience. Before the move to Git, in Source Depot, it was spread across 40+ depots and we had a tool to manage operations that spanned them.

A dispute between a prominent open-source developer and the maker of software used to manage Linux kernel development has forced Linux creator Linus Torvalds to embark on a new software project of his own. The new effort, called "git," began last week after a licensing dispute forced Torvalds to abandon the proprietary BitKeeper software he had used since 2002 to manage Linux kernel development.

The conflict touches on the difference between open-source developers who view Linux's open, collaborative approach as a technically superior way to build software and advocates of free software who see the ability to access and change source code as fundamental freedom.

As a result of the dispute, Torvalds is now working with other Linux developers to create software that can quickly make changes to 17,000 files that make up the Linux kernel, the central component of the Linux operating system. "Git, to some degree, was designed on the principle that everything you ever do on a daily basis should take less than a second," Torvalds said in an e-mail interview.