No.
git.freebsd.org (whithout the c). Github works differently, offering the repo and a web frontend on the same routes.git format-patch) attached, or for really complex changes, a review on phabricator. But I've seen src accepts and handles Github pull requests ... not sure what's the current practice for ports.
Github also has oodles of content mirrors across the globe. So for simply updating your source or ports tree it might be faster and have a more consistent uptime.
The other reason to use github is most people understand pull requests. Using phabricator for reviews is foreign to most people who are not committers.
Interesting. I never experienced any issues with my "asymmetric" setup (pulling from git.freebsd.org) though, so, seems to be "quick enough" to sync.
For the majority of submissions we get on ports, this isn't much of an issue because they are small enough to do the review on bugzilla, but sure, for more complex reviews, that's not suitable.
You might want to give
git-arc a try, meanwhile conveniently available from devel/freebsd-git-devtools: $ git arc patch D12345
Apply the patch in review D12345 to the currently checked-out tree, and
commit it using the review's title, summary and author.Well, I'm not generally against the pull requests like github invented them. The major issue is, as you state yourself, relying on 3rd party infrastructure for "important" bits of information. What really annoys me is having different channels. Maybe, if we really think we want this "pull request" style workflow, hosting something like e.g. forgejo ourselves might help end this zoo of contribution channels.
orts.git (push)forgejo is lightweight enough. Github does do some ci build testing for us. jenkins handles most CI testing. Github handles Linux, MacOS and other weird tests. I learned that the hard way after a commit to Makefile.inc. make universe on the universe machines built ok. It was pointed out to me that Linux cross builds were failing because Linux didn't support architecture word length like FreeBSD does; the CPP variable was left undefined and pre-build failed. I think for the time being we need all repos.
Don't get me wrong, I have no concerns about having a mirror on Github at all, and also I don't think having some "exotic" CI builds there is a problem either. My concern is only about 1) having the history of reviews there instead of own infrastructure (that can be important to understand a specific change later) and 2) having a multitude of contribution channels.
My gut feeling is that gitlab is a somewhat heavy "monster" and something light-weight might be the better option, but that's a detail discussion in the end. I'm personally happy with the current tooling as well, maybe a helper like git-arc needs a bit more advertising. Please just consolidate tooling and processes in some way
.This is why I don't want to have github account, causing I cannot contribute the way. Only Bugzilla, Phablicator, mailing lists, mastodon, matrix and here forums are the possible way for me.
Having a Github account won't do you any harm. But it really makes sense to think through what you want to trust to a 3rd party platform. For my private projects, I'm perfectly fine with Github, reviews are rare and small for these and I make sure to put everything relevant in the commit messages, which are part of the (redundant by nature) git repository data. Of course I still accept contributions by email in
git format-patch, so having a Github account isn't strictly required.Well, you must setup
arc correctly: https://wiki.freebsd.org/Phabricator#Setupgit-arc, see above. Here's an introduction: https://freebsdfoundation.org/wp-content/uploads/2021/11/FreeBSD-Code-Review-with-git-arc.pdfgit-arc has great support for creating and managing a stack of reviews where every review corresponds to a single commit, it unfortunately doesn't support multiple commits in a single review, which is sometimes more appropriate.
git pull doesn't solve these problem(s). So, I delete src and clone again, but the average speed I get when cloning from FreeBSD's git is 1.84MiB/s vs 48.4MiB/s from GH. There are no factors from my side that I can think of to be affecting these speeds since I use the same hardware, software and internet at the same time of day.
Regarding that, you should probably learn how git works and use that to your advantage. If you want to fiddle with code locally, create a local branch (e.g.
git checkout -b local) and then commit your changes there. Then you can rebase that branch onto whatever you track from upstream, e.g. assuming a release branch:git checkout local
git fetch origin releng/14.1:releng/14.1
git rebase releng/14.1That's unfortunate. There's no reason not to pull from Github instead, just be aware it's a read-only mirror and syncing it might lag (very slightly), so it's possible you'll be a few commits behing what you'd get from git.freebsd.org, although not too likely.
It's perfectly fine to use one of the mirrors (Github, Codeberg, GitLab (https://docs.freebsd.org/en/books/handbook/mirrors/#external-mirrors)), the delay is roughly normally a few minutes so it's not you're missing out on something and for a "consumer" it's more than fine. Actually I would encourge people to use one of these as they're as noted by others (SirDice for example) very often noticably faster than the geodns'ed git.freebsd.org hosts.
See also my latest answer directly above. I think the initial question kind of missed an important qualification: recommended for what?
