HEADS UP: FreeBSD changing from Subversion to Git this weekend

ucomp

Active Member

Reaction score: 42
Messages: 239

You keep trying to dispute the words “download and place” – these are ralphbsz’s words.
phew, aha, now I know what you mean(after reading Ralph`s post exactly) really didn't see that ralphbsz is the inventor of "download and place” :)
It has nothing to do with Git, or with distributing FreeBSD code. If you want to talk about TFTP, you should open a new thread.
while I compile and boot mostly from disks , I think netboot has a lot to do with distributing FreeBSD code(on the local network).
also used emulex fc-cards in the past... while I remember on one server I had to replace one with an qlogic because of missing emulex-driver.
And ,No: don`t want to talk about anything like tftp here no more ,
the climate here seems too poisoned and unfocused
(sure not your fault),

nothing bad,
and maybe meet you sometime here again,
until then take care
Regards
 

Jose

Aspiring Daemon

Reaction score: 395
Messages: 551

so, to say a bit clearer: as state of today /Dec/26/2020
https://github.com/freebsd/freebsd master branch
is out of sync
with https://git.FreeBSD.org

while

is in sync with
https://git.FreeBSD.org

so if one forks or clone freebsd-src you won't start with GitHub today(/Dec/26/2020).
Also there's one on Codeberg:

Why limit ourselves to one mirror? Let's collect them all!

First clone the canonical repo so it gets set up as our origin
Code:
time git clone https://git.freebsd.org/src.git                                                           
Cloning into 'src'...
remote: Enumerating objects: 377603, done.
remote: Counting objects: 100% (377603/377603), done.
remote: Compressing objects: 100% (26669/26669), done.
remote: Total 3819016 (delta 371845), reused 350928 (delta 350928), pack-reused 3441413
Receiving objects: 100% (3819016/3819016), 1.13 GiB | 24.16 MiB/s, done.
Resolving deltas: 100% (3024229/3024229), done.
Updating files: 100% (81247/81247), done.
    2m22.19s real     3m45.89s user     0m13.99s system


Now let's add Coderberg and fetch its state
Code:
cd src
git remote add berg https://codeberg.org/FreeBSD/freebsd-src.git
git fetch berg
From https://codeberg.org/FreeBSD/freebsd-src
 * [new branch]              main                             -> berg/main
 * [new branch]              releng/1                         -> berg/releng/1
 * [new branch]              releng/10.0                      -> berg/releng/10.0
 * [new branch]              releng/10.1                      -> berg/releng/10.1
 * [new branch]              releng/10.2                      -> berg/releng/10.2
 * [new branch]              releng/10.3                      -> berg/releng/10.3
 * [new branch]              releng/10.4                      -> berg/releng/10.4
...


Let's check whether the canonical main branch and the Coderberg main branch are the same
Code:
git diff ..berg/main
diff --git a/sys/arm/arm/pmu.c b/sys/arm/arm/pmu.c
index 544962e9ab2..b16ffcafcfa 100644
--- a/sys/arm/arm/pmu.c
+++ b/sys/arm/arm/pmu.c
@@ -36,6 +36,7 @@
 __FBSDID("$FreeBSD$");
 
 #include "opt_hwpmc_hooks.h"
+#include "opt_platform.h"
 
 #include <sys/param.h>
 #include <sys/systm.h>
@@ -49,14 +50,31 @@ __FBSDID("$FreeBSD$");
 #include <sys/pmc.h>
 #include <sys/pmckern.h>
 
+#ifdef FDT
+#include <dev/ofw/openfirm.h>
+#include <dev/ofw/ofw_bus.h>
+#include <dev/ofw/ofw_bus_subr.h>
+#endif
+
 #include <machine/bus.h>
...

Hm, maybe the Coderberg mirror is a little behind? Let's add Gitlab and check
Code:
git remote add gitlab https://gitlab.com/FreeBSD/freebsd-src.git
git fetch gitlab
remote: Enumerating objects: 38377, done.
remote: Counting objects: 100% (38377/38377), done.
remote: Total 294744 (delta 38377), reused 38377 (delta 38377), pack-reused 256367
Receiving objects: 100% (294744/294744), 62.01 MiB | 11.28 MiB/s, done.
Resolving deltas: 100% (82379/82379), completed with 36987 local objects.
From https://gitlab.com/FreeBSD/freebsd-src
 * [new branch]              main                             -> gitlab/main
 * [new branch]              master                           -> gitlab/master
 * [new branch]              releng/1                         -> gitlab/releng/1
 * [new branch]              releng/10.0                      -> gitlab/releng/10.0
 * [new branch]              releng/10.1                      -> gitlab/releng/10.1
 * [new branch]              releng/10.2                      -> gitlab/releng/10.2
 * [new branch]              releng/10.3                      -> gitlab/releng/10.3
 * [new branch]              releng/10.4                      -> gitlab/releng/10.4
...
git diff ..gitlab/main                                                                               
$

Yep, it looks like Coderberg is a little behind. Adding the Github remote and checking what the difference is between the canonical main branch and the Github master branch are left as exercises for the reader.
 

ralphbsz

Son of Beastie

Reaction score: 1,791
Messages: 2,792

I have a really dumb question. The official git repo for FreeBSD is hosted on a set of machines under control of the FreeBSD project, with host names like {cgit,repo,git}.freebsd.org. Those seem to be working fine. They seem to have a geographically spread DNS infrastructure in place, so they should be pretty close to people (mine is within the US). Why does anyone even bother with the read-only mirrors at places like github and gitlab? Why are we even arguing over those? Why don't we just completely ignore them?
 

Jose

Aspiring Daemon

Reaction score: 395
Messages: 551

You certainly don't have to, and I probably will not use any of the mirrors. One convenient thing Git{hub,lab} can do for you is host a remote clone. Github calls these "forks" and they have an easy Web UI for creating them. You would want a remote clone as a backup of any changes you made and also because most of us won't have write access to the canonical Freebsd repos and thus won't be able to push changes to them.

GitHub has a really convenient web UI for casual source code reading. I have no idea why would anyone bother with GitLab, that thing is insufferable.
The Gitlab browser works well enough for me, but I'm not particularly picky about that kind of thing. Is there something specific that bugs you about the interface?

Gitlab started life as an open-source clone of Github back in the day when Github's on-premises "product" was a sick joke. They used to be very, very similar. I haven't really kept up with how they've changed.
 

shkhln

Daemon

Reaction score: 749
Messages: 1,826

The Gitlab browser works well enough for me, but I'm not particularly picky about that kind of thing. Is there something specific that bugs you about the interface?
Clutter, low contrast (in menus), slowness. I don't have the same reaction to Bitbucket for example, so it's not like I can't tolerate any alternatives.

Compare https://gitlab.com/FreeBSD/freebsd-...d1f1152e532ff7b489f7c/libexec/rtld-elf/rtld.c with https://github.com/freebsd/freebsd-src/blame/main/libexec/rtld-elf/rtld.c. GitLab has an obnoxious overhanging panel at the top of the page, a side bar I don't care about and the commit descriptions taking 3 (code) lines of height, which looks annoying when they correspond to only one line of code.
 

mickey

Aspiring Daemon

Reaction score: 217
Messages: 631

Just wondering about the disk space usage... Previously I had used svnsync to maintain an on-premises mirror of the FreeBSD src SVN repository which was using over 7 GiB on an lz4 compressed ZFS dataset. Now after mirroring the GIT repository it only uses about 1.3 GiB. Not that I don't appreciate the extra disk space, but ... how comes?
 

ucomp

Active Member

Reaction score: 42
Messages: 239

I have a really dumb question.
no, opposite of dumb, that's the first reasonable question I read here here, namely the one it's about :cool: :

Why does anyone even bother with the read-only mirrors at places like github and gitlab?
O.K.,
first we should explain the term mirror compared to a fork.

A fork is first a onetime-download&place( (c) 2020 ralphbsz ),... couldn't resist.. 😁..
it initializes the hashes which will then be manually download&place(!) again and again with the command : git pull

while

a mirror is not a onetime thing, it is instead a stream which automatically
updates the source tree e.g. every 5 minutes or whatever count of minutes.

now to the term read-only mirror :
when you fork from a mirror of the original git-server @freebsd.org
e.g. to YOUR(!!!) GitHub-account that will NOT (!!!) be a read only mirror.
So you would first fork from @freebsd.org , setup that fork to point a
mirror of itself to your GitHub-account to which then you will have
read&write-access.
and that will be your origin to your local(or remote-) machine(s !!!).

So the 'HUB' in the name GitHub has reason.

the answer to your excellent question is:
we don't bother with readonly mirrors, instead we mirror e.g. to GitHub
to make it read&WRITE.


this example of a setup has good reasons for developers, but since no one has asked why,
that's another thing because I have become cautious about answering question which were not asked ;-)

Regards
 

ucomp

Active Member

Reaction score: 42
Messages: 239

so, as described above & to shine a light on all that GitHub -thing:

GitHub is the HUB which serves as (code-)origin to your local(or remote) machine(s).

same as your USB-Hub serves your local USB-gadgets,.

GitHub distributes code , your USB-Hub distributes devices.

while you can use the web-fronted of GitHub that's not the reason for using it.
the reason is pull&push( and some other things).

... as gitlab does(but nobody asked about the differences ;-)
 

ucomp

Active Member

Reaction score: 42
Messages: 239

the main-branch -mirror is now on GitHub, as I just saw :
(it was called master-branch before, which is now obsolete and archived).

for those not yet familiar with it:
main == FreeBSD13 , you will also see e.g branches :
stable/12
and
stable/11
on GitHub.
 

msplsh

Well-Known Member

Reaction score: 115
Messages: 351

I have a really dumb question. ... Why does anyone even bother with the read-only mirrors at places like github and gitlab?
Because some people like those places. Some people do not.

Why are we even arguing over those?
Because other people want everyone to know about their crusade against things they don't like.

Why don't we just completely ignore them?
That's what a completely rational person would do if they didn't like those services, didn't need them to continue operating, and considered them to not be a threat to the service they were using.
 

Jose

Aspiring Daemon

Reaction score: 395
Messages: 551

GitHub is the HUB...
Git has no concept of hubs or spokes. All repositories are stand-alone, completely independent peers.
...which serves as (code-)origin to your local(or remote) machine(s).
You DO NOT HAVE TO USE GITHUB. You can clone any of the mirrors or the canonical repository as I have shown above. There's really no sense in cloning one of the mirrors, as [user=30524]Ralphbsz[/user] points out. Why would you risk using a stale copy?

Furthermore, there's nothing special about the remote called "origin":
"Just like the branch name 'master' does not have any special meaning in Git, neither does 'origin'. While 'master' is the default name for a starting branch when you run git init which is the only reason it’s widely used, 'origin' is the default name for a remote when you run git clone. If you run git clone -o booyah instead, then you will have booyah/master as your default remote branch."

You don't have to have a remote called "origin" if you don't want to. You can change the URL for the "origin" remote at any time. Git really is distributed and really doesn't care.
while you can use the web-fronted of GitHub that's not the reason for using it.
the reason is pull&push( and some other things).
Push and pull are standard Git functionality. They have absolutely nothing to do with Github.
...it initializes the hashes which will then be manually download&place(!) again and again with the command : git pull
Commit hashes are a function of the state of the tree at a particular change set. They are completely independent of how or where the repository is hosted, and are calculated when git-commit(1) runs, not when the repository is cloned or when git-pull(1) is invoked. The default mechanism for a git pull is a git-fetch(1) followed by a git-merge(1). The merge might create a merge commit depending on your settings, and this would create a new hash (it is a commit, after all). Existing hashes would not be affected.
Because other people want everyone to know about their crusade against things they don't like.

That's what a completely rational person would do if they didn't like those services, didn't need them to continue operating, and considered them to not be a threat to the service they were using.
Like or dislike has nothing to do with it. I want to dispel the notion that Git and Github are the same thing. I don't want anyone to think that you have to use Github to access the Freebsd source. I can see why reasonable people would have a problem with contributing freely to a project beholden to a for-profit company.
 

ucomp

Active Member

Reaction score: 42
Messages: 239

Git has no concept of hubs or spokes. All repositories are stand-alone, completely independent peers.

You DO NOT HAVE TO USE GITHUB. There's really no sense in cloning one of the mirrors, as [user=30524]Ralphbsz[/user] points out. Why would you risk using a stale copy?

o.k, let`s shine light on this things:
1st: correct: nobody is forced to use GitHub to work with git, I thought that was one of the really few things which were often enough cleared up here .

but
everybody can use GitHub, like millions others do (or gitlab or an own server like freebsd.org) .
---

There's really no sense in cloning one of the mirrors, as [user=30524]Ralphbsz[/user] points out. Why would you risk using a stale copy?
it's the opposite in my example above:
I do not clone the fbsd-GitHub-mirror. Instead I setup my fbsd-GitHub-repo as an fbsd-mirror .
why? simple answer : no more need of git pull(upstream)/git push(MYorigin) to the GitHub-repo. So it's NOT a clone nor a fork, it's a mirror (which can than be cloned to everywhere). but why? because it`s then a read/write mirror instead of readonly.
( while technically a mirror is NEVER readonly because the main thing it does is write and write and write and...)

.....
Furthermore, there's nothing special about the remote called "origin":
"Just like the branch name 'master' does not have any special meaning in Git, neither does 'origin'. While 'master' is the default name for a starting branch when you run git init which is the only reason it’s widely used, 'origin' is the default name for a remote when you run git clone. If you run git clone -o booyah instead, then you will have booyah/master as your default remote branch."

You don't have to have a remote called "origin" if you don't want to. You can change the URL for the "origin" remote at any time. Git really is distributed and really doesn't care.

Push and pull are standard Git functionality. They have absolutely nothing to do with Github.
yes, that's all correct and a confusing detail for newcomers:
git doesn't care about names,

you even can fork FreeBSD on Github and call it OpenBSD-src 😂

but why are those names widely used and we use it here :
because we can try to talk about the same when we use terms like remote, upstream, origin, fork, clone and so on...

Push and pull are standard Git functionality. They have absolutely nothing to do with Github.

Commit hashes are a function of the state of the tree at a particular change set. They are completely independent of how or where the repository is hosted, and are calculated when git-commit(1) runs, not when the repository is cloned or when git-pull(1) is invoked. The default mechanism for a git pull is a git-fetch(1) followed by a git-merge(1). The merge might create a merge commit depending on your settings, and this would create a new hash (it is a commit, after all). Existing hashes would not be affected.
absolutely right

I can see why reasonable people would have a problem with contributing freely to a project beholden to a for-profit company.
not worth to talk about it because that implies that people who contribute to or use GitHub
were not reasonable.
that's all only Blabla . we have e.g. developed openjdk bsd-port on GitHub .
boah , we must have been really unreasonable, so let's delete the openjdk-port from FreeBSD
because we have political incorrectly ran with the devil 😂
what a f*cked up crap-discussion, let's stay technical ;-)


Have a good new year!

Regards
 

msplsh

Well-Known Member

Reaction score: 115
Messages: 351

I want to dispel the notion that Git and Github are the same thing
Fair. People seem to have serious problems with this.
I can see why reasonable people would have a problem with contributing freely to a project beholden to a for-profit company.
Ok, but there's no contribution going on here. Just use. Nobody cares about other people's problems that can be solved by the other person ignoring the thing that is bothering them with zero consequences for doing so.
 

ucomp

Active Member

Reaction score: 42
Messages: 239

...Just use. Nobody cares about other people's problems ....
you haven't asked me :) but I clicked `reply` because something of what you say sounds sad.

But we don't have to be so sad today ;-)...

just NOT use wouldn't be the same as take care about other people`s problems ,


So there should be room for improvement in terms of compassion for other people`s problems, even though we(whoever that is) are using GitHub ;-)

by the way, I used google-translator for this post, beholden to a for-profit company,
please forgive me 😁

Have a good new year!

Regards
 

msplsh

Well-Known Member

Reaction score: 115
Messages: 351

So there should be room for improvement in terms of compassion for other people`s problems
You didn't finish the quote.

If people can solve their problem by ignoring something (github), then they should do that. If ignoring something (github) is a zero-consequence action, I can't think of a reason why they should not ignore the thing (github). It's a self-inflicted problem if they won't ignore it (github) so there is little room for compassion.
 

Jose

Aspiring Daemon

Reaction score: 395
Messages: 551

Ok, but there's no contribution going on here. Just use. Nobody cares about other people's problems that can be solved by the other person ignoring the thing that is bothering them with zero consequences for doing so.
I care if other people's problem with Github is going to prevent them from contributing because they have been led to believe that "Freebsd is using Git" means "You have to use Github to contribute to Freebsd".
...no more need of git pull(upstream)/git push(MYorigin) to the GitHub-repo...
What happens when you push to the main branch of your mirror? Your version of the main branch diverges from the main branch of the canonical repo. The next time you git rebase main you might get clean results that are spurious, and your pull request against the canonical main branch might be rejected because of conflicts you can't even see.
not worth to talk about it because that implies that people who contribute to or use GitHub
were not reasonable.
Absolutely does not imply that in any way, but let me be forcefully clear. I have absolutely no problem with anyone using Github, and have used it myself to contribute to projects that are hosted there exclusively. However, many people I respect would refuse to make open-source contributions to any scheme that had any kind of for-profit angle. They would expect to be paid for that, and handsomely.

I have a big problem with making people believe that they're forced to use Github to contribute to Freebsd. It's simply not true, and probably counterproductive. Yes, I'm going to keep repeating this.
 

msplsh

Well-Known Member

Reaction score: 115
Messages: 351

I care if other people's problem with Github is going to prevent them from contributing because they have been led to believe that "Freebsd is using Git" means "You have to use Github to contribute to Freebsd".
Also fair. If they won't believe you after you explain it to them over and over, the value of their contributions might come into question.
 

ucomp

Active Member

Reaction score: 42
Messages: 239

Olè guys and happy new year !
I now have read yours link and statements to the YouTube-dl-thing... : so it wasn't GitHub`s idea
to remove the dl-repo and Instead they were forced by another company to remove it? did I understand that correctly?
So instead of blaming GitHub we now have to stop watching YouTube? is that a correct analysis? ;-)
if so, that's good news, so instead of watching videos the whole day we can
browse and learn understanding parts of FreeBSD-src and edit code on GitHub,
The world changes to a better place :) Ha Ha

And don't forget:
You are totally forced to use GitHub because FreeBSD`s web-frontend is so ugly and lacks functionality :) Ha Ha

for those who have read the FreeBSD source code and then realize that the problems of the human race are far greater than they could ever imagine 😂 :
please don’t worry, you are not forced to use GitHub, instead you can feel free to get back
to YouTube e.g to watch a good Clint Eastwood-western , catched by YouTube-dl .

-- ah, forgot: ---
What happens when you push to the main branch of your mirror? Your version of the main branch diverges from the main branch of the canonical repo. The next time you git rebase main you might get clean results that are spurious, and your pull request against the canonical main branch might be rejected because of conflicts you can't even see.
while good point what you say, there's no problem for me with, because I fork the mirror again to a place where I can do every possible chaos of code without breaking something...that's the comfortable thing with those "HUBs", you can do a lot with some clicks as long as you know what you're doing.
.....pull request .......
I was amazed that no one has gone into it so far, so thanks for that.
so that will be the next great question:
How can we send politically correct ;-) PullRequests to FreeBSD?
 

Jose

Aspiring Daemon

Reaction score: 395
Messages: 551

Olè guys and happy new year !
Is this some kind of ethnic joke? BTW the grave accent is not a thing in Spanish. The correct way to spell that word is olé. Also, I'm from Latin America, and we don't use it very often.
...while good point what you say, there's no problem for me with, because I fork the mirror again to a place where I can do every possible chaos of code without breaking something...that's the comfortable thing with those "HUBs", you can do a lot with some clicks as long as you know what you're doing.

I was amazed that no one has gone into it so far, so thanks for that.
so that will be the next great question:
How can we send politically correct ;-) PullRequests to FreeBSD?
Just so you know, Google translate is making you sound completely insane.
 

ucomp

Active Member

Reaction score: 42
Messages: 239

Is this some kind of ethnic joke? BTW the grave accent is not a thing in Spanish. The correct way to spell that word is olé. Also, I'm from Latin America, and we don't use it very often.
No, I didn't even think of anything ethnic. As a football fan, I use this word when players of my favourite team push the ball to one another.

so let me please try my Spanish WITHOUT google translate, although it's a long time ago when I was very often in Latin America :

porque esto es la verdad que google translate no siempre hables la verdad ,
yo olvido mucho la idioma español pero yo recuerdo bueno tu bien país
. 😂

wow, `have put it in the translator and doesn't work quite good ...
 

ucomp

Active Member

Reaction score: 42
Messages: 239

Phabricator
of course, as state of today phab is used. but will FreeBSD accept PRs from e.g. public GitHub/GitLab in the near future and will those collaboration platforms be accepted as a replacement for phab-reviews, issue-reports etc.?
 

jb_fvwm2

Daemon

Reaction score: 193
Messages: 1,752

git clone -b stable/12 --depth 1 https://git.freebsd.org/src.git src works
as svn did for a non-existant yet /usr/src... unsure if it has been
posted yet in this thread, but probably also should be somewhere in /usr/src/UPDATING as well as an equivalent for /usr/ports/UPDATING when
that also switches.
.............
corrections welcome.
.............
Information came from one of the mailing lists just very recently.
 

msplsh

Well-Known Member

Reaction score: 115
Messages: 351

will FreeBSD accept PRs from e.g. public GitHub/GitLab in the near future and will those collaboration platforms be accepted as a replacement for phab-reviews, issue-reports etc.?
That's a request for a "forward looking statement" and none has been made.

I don't see why this would change from the current status of "no" and "no" given that it would bifurcate things.
 
Top